Bug #94647 Memory leak in MEMORY table by glibc
Submitted: 14 Mar 2019 4:45 Modified: 15 Mar 2019 14:19
Reporter: Wallace Ko Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Memory storage engine Severity:S3 (Non-critical)
Version:5.7 OS:Debian
Assigned to: CPU Architecture:Any

[14 Mar 2019 4:45] Wallace Ko
Description:
Memory allocated by glibc for MEMORY table is not released completely after table is dropped.

How to repeat:
Steps to reproduce are described in detail at https://dba.stackexchange.com/q/231661

Similar bug is also reported in MariaDB at https://jira.mariadb.org/browse/MDEV-14050

In short, several memory tables of observable size are created and dropped. Although performance_schema schema shows that malloc and free in heap is balanced, but not all memory is released from mysqld due to implementation of glibc.

By changing malloc-lib to jemalloc, memory is released after table drop.

Suggested fix:
malloc_trim(0) or equivalent may need to be called to request memory allocator to release free memory.
[15 Mar 2019 14:19] MySQL Verification Team
Hi Mr. wtel,

Thank you for your report.

What you describe is a typical behaviour of the GNU malloc library. We are not in charge of maintaining that library. Also, on Linux and some other operating systems, you can easily change to the malloc library of your choice.

Even with GNU malloc library, you can free memory by writing a short C program which would only called calloc() with the parameter that is slightly larger then the available memory on the system.

In short, this is not our bug.