Bug #35661 | legacy and incorrect memory formula and message written to error log after crash | ||
---|---|---|---|
Submitted: | 28 Mar 2008 22:19 | Modified: | 10 Oct 2018 12:09 |
Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server: Errors | Severity: | S3 (Non-critical) |
Version: | 4.1, 5.0, 5.1, 5.5 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[28 Mar 2008 22:19]
Shane Bester
[31 Mar 2008 17:51]
Sveta Smirnova
Thank you for the reasonable feature request.
[8 Sep 2008 11:09]
MySQL Verification Team
In addition, i would like to see the number of malloc's that failed during the server's uptime. Can we print this is to the crash log?
[18 Feb 2009 12:34]
MySQL Verification Team
http://www.mysqlperformanceblog.com/2009/02/12/how-much-memory-can-mysql-use-in-the-worst-...
[18 May 2010 7:39]
MySQL Verification Team
impacts all users who are conned into believing wrong. just remove the incorrect formula and be done with it.
[28 Jul 2010 9:58]
Roel Van de Paar
Bug #55594 (referring to InnoDB variables) was marked as a duplicate of this one.
[29 Jul 2010 2:09]
Roel Van de Paar
Note that part of the InnoDB information is already available: it is shown in SHOW ENGINE INNODB STATUS: ---------------------- BUFFER POOL AND MEMORY ---------------------- Total memory allocated 138412032; in additional pool allocated 0 Dictionary memory allocated 39020 Buffer pool size 8192 Free buffers 1684 Maybe the code for this can be re-used/referenced.
[29 Nov 2010 17:20]
Sasha Pachev
Yes, the formula is from back before the InnoDB days when those variables were often the primary cause of large allocations. Nowadays it is rather irrelevant. mysqld could still use up to that much memory, but it is likely to be using more.
[21 Aug 2013 20:05]
MySQL Verification Team
probably a duplicate of http://bugs.mysql.com/bug.php?id=1694
[22 Jan 2015 2:57]
Roel Van de Paar
http://bugs.mysql.com/?id=75536
[10 Oct 2018 12:10]
Steinar Gunderson
Was filed and fixed as #92731 / #28773322.