MySQL Bugs: #108141: Memory leak after upgrade from 8.0.28 to 8.0.29+

Bug #108141	Memory leak after upgrade from 8.0.28 to 8.0.29+
Submitted:	15 Aug 2022 15:47	Modified:	16 Aug 2022 12:47
Reporter:	Jaroslav Herber	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	8.0.29 and 8.0.30	OS:	Ubuntu (20.04.4 LTS)
Assigned to:		CPU Architecture:	x86

Description:
We have a ubuntu 20.04.4 LTS with 16 GB of RAM.

End of July we updated our mysql-server from 8.0.28 to 8.0.29.
Since then the mysqld process gradually increasing RAM-consumption and the oom killer kills mysqld process one, sometimes two times a day.

Before update we had contant 70 % free RAM on the machine. Since update mysqld consumes 1% of RAM every 10-20 minutes.

Update to 8.0.30 didn't fixed the memory leak.

We found out, that a window program, which uses MySQL Connector/NET to connect to our MySql Server, caused this leak. But we don't know why. Every system var and status var in the mysql server looks ok - no signs of too much memory are visible.

The mentioned windows program uses prepared statements, which are not closed. In fact there is no closing function for prepared statements in MySQL Connector/NET...

SHOW GLOBAL status like 'com_stmt%';
-> Com_stmt_prepare increases slowly while Com_stmt_close stays 0.
Com_stmt_prepare gets even bigger (after ~8 hours: > 30000) than max_prepared_stmt_count (16382)
It's hard to tell, if this has something to do with the memory leak.

How to repeat:
We have only a few custom mysqld configs, which were fine with 8.0.28:
key_buffer_size   = 16M
max_allowed_packet      = 999M
innodb_buffer_pool_size = 4G
innodb_log_file_size = 256M
innodb_log_buffer_size = 16M
max_connections = 151
tmp_table_size = 16M
thread_cache_size = 8

pmap of the mysqld-process shows a lot of this lines:

Address           Kbytes     RSS   Dirty Mode  Mapping
....
00007f1e58000000   65488   49020   49020 rw---   [ anon ]
00007f1e5bff4000      48       0       0 -----   [ anon ]
00007f1e5c000000   65492   60984   60984 rw---   [ anon ]
00007f1e5fff5000      44       0       0 -----   [ anon ]
00007f1e60000000   65520   51440   51440 rw---   [ anon ]
00007f1e63ffc000      16       0       0 -----   [ anon ]
00007f1e68000000   65452   59584   59584 rw---   [ anon ]
00007f1e6bfeb000      84       0       0 -----   [ anon ]
00007f1e6c000000   65492   49028   49028 rw---   [ anon ]
00007f1e6fff5000      44       0       0 -----   [ anon ]
00007f1e70000000   65508   63180   63180 rw---   [ anon ]
00007f1e73ff9000      28       0       0 -----   [ anon ]
00007f1e74000000   65516   55144   55144 rw---   [ anon ]
00007f1e77ffb000      20       0       0 -----   [ anon ]
00007f1e78000000   65476   52880   52880 rw---   [ anon ]
00007f1e7bff1000      60       0       0 -----   [ anon ]
00007f1e7c000000   65532   59576   59576 rw---   [ anon ]
....

looks like mysqld forgetting some RAM allocations after reaching 64k.

Hi Mr. Herber,

Thank you for your bug report.

However, not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.mysql.com/how-to-report.php .....

Your instructions are very scarce and even those are sketchy. You have put this bug under the category of the server, while in the text you claim that a bug is in our Connector / NET. In the same time you are not sure whether you are using that connector correctly in your applications.

We need a fully repeatable test case, which you have not provided.

If you can provide more information, as per the above instructions, feel free to add it to this bug and change the status back to 'Open'.  

Thank you for your interest in MySQL.