Bug #100114 | bluk_insert may lead to memory leak | ||
---|---|---|---|
Submitted: | 5 Jul 2020 8:03 | Modified: | 11 Jul 2020 16:03 |
Reporter: | tandon zhai | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server | Severity: | S2 (Serious) |
Version: | 5.7.25 | OS: | CentOS (7.6) |
Assigned to: | CPU Architecture: | Any |
[5 Jul 2020 8:03]
tandon zhai
[6 Jul 2020 15:23]
MySQL Verification Team
Hi Mr. zhai, Thank you for your bug report. We can not verify it, based on the info that you have provided us. I could not reproduce it, bug it might be because I do not use GNU malloc. What you describe is a typical behaviour of GNU malloc, or of the further usage of the InnoDB buffer pool. In first case, OS is keeping memory with the process and in the second one, memory is actually allocated only when it is accessed. To prove memory leak you should use ASAN or some other professional tool.
[7 Jul 2020 12:47]
tandon zhai
Hi, did you use the /etc/my.cnf and /etc/init.d/mysql i provide previously? I think the malloc lib doesn't matter, i tryed the je and tc, but the result both shown that the rss become 5.6G and the buffer pool was only 128M. and i will try ASAN to see if there is any memory problem. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 22426 mysql 20 0 6237504 5.6g 12204 S 0.3 35.5 1:29.86 mysqld [mysqld_safe] malloc-lib=/usr/lib64/libjemalloc.so.1 malloc-lib=/usr/lib64/libtcmalloc.so.4 [root@co160 ~ 20:25:13]# lsof -p 22426 | grep malloc mysqld 22426 mysql mem REG 253,0 301136 4197394 /usr/lib64/libtcmalloc.so.4.4.5 echo 'INSERT INTO ztd.ztd VALUES ' > ztd.sql num=1 while [[ "$num" -le "999999" ]] do echo '(1,"This is a ztd value"),' >> ztd.sql let num+=1 done echo '(1,"This is a ztd value");' >> ztd.sql [root@co160 ~ 20:40:22]# wc -l ztd.sql 1000001 ztd.sql
[7 Jul 2020 13:09]
MySQL Verification Team
Hi, Yes, I did ..... only changes that I made were to some paths ....
[7 Jul 2020 13:10]
MySQL Verification Team
Also, please, obligatory use our latest available release for either 5.7 or 8.0.
[7 Jul 2020 13:13]
MySQL Verification Team
5.7.30 memory heap showing the functions who consume memory.
Attachment: mybin.hprof.2031.heap.pdf (application/pdf, text), 13.77 KiB.
[7 Jul 2020 13:16]
MySQL Verification Team
I repeated a 6G memory usage on 5.7.30. Ran under profiler. Simple solution is to restrict the parser's memory (unlimited by default!) https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_parser_max_mem... Then you get: ERROR 3170 (HY000) at line 1 in file: 'ztd.sql': Memory capacity of 104857600 bytes for 'parser_max_mem_size' exceeded. Parser bailed out for this query.
[11 Jul 2020 16:03]
tandon zhai
sorry, i made a mistake. actually, for 5.7.30, if i use /usr/lib64/libjemalloc.so.1, the rss will decrease after the session disconnection, and if i use /usr/lib64/libtcmalloc.so.4 or /usr/lib64/libc-2.17.so, the rss will still be quite big. for 8.0.20, the malloc lib doesn't matter. the rss decrease to normal standard after disconnection so, just as what you said, we can use jemalloc to avoid big rss kept by mysqld. thank you for you time.
[12 Jul 2020 7:14]
MySQL Verification Team
This particular report does not represent a bug. I did anyway create an internal feature request to prevent the situation happening: Enh 31590648 - MAKE A SMALLER DEFAULT VALUE FOR PARSER_MAX_MEM_SIZE
[13 Jul 2020 12:47]
MySQL Verification Team
Mr. zhai, We are glad that our conclusions were correct.