MySQL Bugs: #77616: MySQL memory not release after connection closed

Bug #77616	MySQL memory not release after connection closed
Submitted:	3 Jul 2015 21:58	Modified:	9 May 2018 15:10
Reporter:	Liping Gao	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Connection Handling	Severity:	S3 (Non-critical)
Version:	5.6.22, 5.6.23, 5.6.25	OS:	Solaris (SunOS 5.11 11.2 sun4v sparc sun4v)
Assigned to:		CPU Architecture:	Any
Tags:	memory leak, Memory not release

Description:
MySQL server memory usage never release after connection closed. For the total 3.6G database with fairly small buffer size.

How to repeat:
Install MySQL 5.6.22 or 5.6.23 on Solaris Sun Sparc 11 server with below buffer size setting, run query and close the connection after query is complete. 

buffer size setting:

# innodb management parameter 

innodb_buffer_pool_size = 3G #(50-80% of RAM, default 8M) 
innodb_log_file_size = 250M #(25% of buffer pool, default 48M) 
innodb_flush_log_at_trx_commit = 0 #flush each second, default is 1 
innodb_thread_concurrency = 6 #(2 times of CPUs plus disks) 
innodb_file_per_table = 1 #one innodb file for one table 
innodb_purge_threads = 4 #default is 1 
innodb_undo_tablespaces = 4 #default is 0, only at create time 
innodb_undo_logs = 8 #default is 128 

explicit_defaults_for_timestamp = TRUE 

# reporting variables 
join_buffer_size = 2M 
sort_buffer_size = 2M 
read_rnd_buffer_size = 2M 

host_cache_size = 0 #Disable host caching for DNS resolution 

# expire binary logs after three days 
expire_logs_days = 3 

# max concurrency connection on the server 
max_connections = 500 

[mysqldump] 
quick 
max_allowed_packet = 256M 

[mysql] # mysql client 
prompt = \\u@\\h [\\d]>\\_ 
no-auto-rehash #Disables auto table/column name completion, MySQL runs faster 

[mysqld] # mysql server 
max_allowed_packet = 256M

Suggested fix:
release the memory after connection is closed or Cap the MySQL memory usage

What is the status of this?

Hi,

We have seen this behaviour thousands of times and we do know the exact cause of this behaviour.

On all operating systems, malloc() library and / or brk() system call, does not release memory that is freed by some process. MySQL frees all memory allocated to any connection, which is done automatically. However, malloc libraries  keep that chunk of memory attached to the process, but internally tagged as "unused". Internally means that this flag is seen only by malloc library. So, when next time process asks for memory allocation, malloc() library just gives it back (if possible) memory that is already attached to the process. That way, entire process is running faster, since many calls to the kernel are therewith saved.

Some malloc libraries, like GNU or Solairs, do allow tuning of how malloc library works, but it only works up to certain degrees and for large allocations. You will get memory freed and very fast when total memory allocation runs up to the limits of RAM.

In short, this has nothing to do with our software and is not a bug at all ......