Bug #91024 loop query multi-database through one connection pool cause memory leak

• Submitted: 25 May 2018 8:28
• Modified: 19 Mar 2019 10:07
• Reporter: mark zhang
• Status: Can't repeat
• Category: MySQL Server: Optimizer
• Severity: S3 (Non-critical)
• Version: 5.6,5.7,8.0
• OS: CentOS
• CPU Architecture: Any

[25 May 2018 8:28] mark zhang

Description:
we have 20 databases in a instance,per database has 100 tables with a same schema.
we start a test program which connect these databases through one connection pool , get data in loop like the following opertion(lid is primary key):

select count(lid) from p2p0.tbInent0
......
select count(lid) from p2p0.tbInent99
...
select count(lid) from p2p19.tbInent1900
.....
select count(lid) from p2p19.tbInent1999

we found that used memory occupied by mysql continues to grow,and can't be released even we close the connection/exit program.when we restart the test program again,the used memory continue to grow。For loop test,finally cause OOM.Is this a mysql memory leak case?

How to repeat:
every time

[25 May 2018 8:48] mark zhang

memory drain up  online

Attachment: drainup.jpg (image/jpeg, text), 235.12 KiB.

[25 May 2018 8:50] mark zhang

upload available memeory in product system

[25 May 2018 12:12] MySQL Verification Team

Hello mark zhang,

Thank you for the report.
In order to confirm the issue at our end, we need exact repeatable test case(test program, logical dump of one of the schema) and configuration(my.cnf or my.ini whichever used) file from your environment. If the data you need to attach is more than 3MB, you should create a compressed archive of the data and a README file that describes the data with a filename that includes the bug number (recommended filename: mysql-bug-data-91024.zip) and upload one to sftp.oracle.com. Your Oracle Web account ([e-mail]) and a client that supports SFTP are required in order to access the SFTP server.
To upload the file to sftp.oracle.com:
1.	Open an SFTP client and connect to sftp.oracle.com. Specify port 2021 and remote directory /support/incoming/.
2.	Log in with your username ([e-mail]) and password.
3.	Upload the archive to /support/incoming.
4.	Once you have uploaded the file, add a comment to this bug to notify us about it.
Example: sftp -oPort=2021 -oUser=[e-mail] sftp.oracle.com:/support/incoming

Thanks,
Umesh

[4 Jun 2018 7:26] mark zhang

Thanks Umesh,I've upload enclosed file named mysql-bug-data-91024.zip into the directory "support/incoming"

[25 Jun 2018 2:07] mark zhang

how about it?

[26 Jun 2018 13:21] MySQL Verification Team

I have not seen with provided schema(created 20 schema, each with 2000 tables + 81 records each) and maven project as I tried to simulate with other ways. This week I'm going to use your maven setup and check - could you please confirm which MySQL Connector/J, maven/jdk version you are using? Thank you!

Regards,
Umesh

[27 Jun 2018 2:45] mark zhang

mysql connector:JDBC  
connect pool:commons-dbcp-1.4.jar
maven 4.0.0.0
jdk:1.7

Thanks for your supporting

mark zhang
best regards

[23 Jul 2018 13:15] mark zhang

how about it ?thanks

[23 Jul 2018 13:22] MySQL Verification Team

I've not seen this issue so far at my end, will test this week with the old c/j version(5.1.30, was trying with 5.1.46) and get back to you. Also, could you please confirm whether the query is ""SELECT count(lId) FROM tbBorrowIntent" or ""SELECT * FROM tbBorrowIntent"? Thank you!

Regards,
Umesh

[31 Jul 2018 1:14] mark zhang

Thanks.That is "select count(lId) from XXXXX"

[19 Mar 2019 10:07] MySQL Verification Team

Thank you for your patience, I attempted to reproduce this many many times but never noticed any memory leak issues even when I started it with valgrind. I would suggest you to upgrade C/J version from 5.1.30 to latest C/J version.

If you are able to reproduce using latest C/J version, feel free to add it to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.