Bug #86082 memory leak? in mysql causes system to max ram and swap out
Submitted: 26 Apr 2017 3:44 Modified: 26 May 2017 16:05
Reporter: mike coutinho Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.7.18 OS:Red Hat
Assigned to: CPU Architecture:Any

[26 Apr 2017 3:44] mike coutinho 
Description:
I am building an application and my 2 test environments are running MySQL 5.7.18.  The app is built in php.  Every day, my test servers hang and take about 5 minutes to come back up.  The servers are running apache and MySQL and have no load other than two developers working on it.  

I have a production environment that has the exact same database schema and php files running MySQL 5.5 and I do not have a problem. The two test environments that I have running 5.7 regularly go out to lunch and have problems.  Right now, the test servers are running in a VM environment with Red Hat Enterprise 7, 8 gb ram, dual processors and have 2 gb swap.  When I start using MySQL during the day, memory climbs to 100% of ram and then eventually takes over all of the swap.  I have restarted the mysqld process and things go back to normal, but it quickly jumps up over a course of a couple minutes of work on the server. 

Being that my production environment is not having this problem, my only conclusion is that it is MySQL 5.7.  I can attempt to diagnose the problem if you have specific things that you would like me to try.  I tried to make changes based on the percona web tool that suggests changes to the application, but that didn't seem to work. I also tried some of the suggestions that were posed during the related bug for MySQL 5.7.13 that was introduced in 5.7.8.  That didn't seem to have any change to the behavior.

How to repeat:
Restart MySQL and then start browsing on the application I am building.  MySQL eventually takes over all of the available ram on the system.
[26 Apr 2017 16:05] MySQL Verification Team 
Hi!

Thank you for your bug report. Please, do know that we can accept only those bugs that are verifiable. This means that a reporter has to provide the analysis of the code which demonstrates the leak or the test case in SQL that demonstrate that memory is not released to the GNU malloc, which is mostly used on Red Hat systems.

For the start , you can analyze the configuration of your server and calculate the potential memory that could be allocated for the maximum number of threads that you have observed.
[27 May 2017 1:00] Bugs System 
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".