线上mysql内存持续增长直至内存溢出被killed分析（已解决）

来新公司前，领导就说了，线上生产环境Mysql库经常会发生日间内存爆掉被killed的情况，结果来到这第一天，第一件事就是要根据线上服务器配置优化配置，同时必须找出现在mysql内存持续增加爆掉的原因，虽然我主业已经不是数据库更不是dba了。看了下mysql占用内存区域的分布：

[root@iZ23nn1p4mjZ osm-all]# pmap -x 5524
5524: /usr/local/Percona-Server-5.7.16-10-Linux.x86_64.ssl101/bin/mysqld --basedir=/usr/local/Percona-Server-5.7.16-10-Linux.x86_64.ssl101 --datadir=/usr/local/Percona-Server-5.7.16-10-Linux.x86_64.ssl101/data --plugin-dir=/usr/local/Percona-Server-5.7.16-10-Linux.x86_64.ssl101/lib/mysql/plugin --user=mysql --log-error=/usr/local/Percona-Server-5.7.16-10-Linux.x86_64.ssl101/data/iZ23nn1p4mjZ.err --open-files-limit=32767 --pid-file=/usr/local/Percona-Server-5.7.16-10-Linux.x86_64.ssl101/data/iZ23nn1p4mjZ.pid --po
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 22772 4876 0 r-x-- mysqld
0000000001c3c000 1628 616 272 rw--- mysqld
0000000001dd3000 836 428 428 rw--- [ anon ]
00000035c2c00000 128 20 0 r-x-- ld-2.12.so
00000035c2e1f000 4 4 4 r---- ld-2.12.so
00000035c2e20000 4 4 4 rw--- ld-2.12.so
00000035c2e21000 4 4 4 rw--- [ anon ]
00000035c3000000 4 4 0 r-x-- libaio.so.1.0.1
00000035c3001000 2044 0 0 ----- libaio.so.1.0.1
00000035c3200000 4 0 0 rw--- libaio.so.1.0.1
00000035c3400000 1576 336 0 r-x-- libc-2.12.so
00000035c358a000 2048 0 0 ----- libc-2.12.so
00000035c378a000 16 16 8 r---- libc-2.12.so
00000035c378e000 4 4 4 rw--- libc-2.12.so
00000035c378f000 20 12 12 rw--- [ anon ]
00000035c3800000 92 52 0 r-x-- libpthread-2.12.so
00000035c3817000 2048 0 0 ----- libpthread-2.12.so
00000035c3a17000 4 4 4 r---- libpthread-2.12.so
00000035c3a18000 4 4 4 rw--- libpthread-2.12.so
00000035c3a19000 16 4 4 rw--- [ anon ]
00000035c3c00000 8 0 0 r-x-- libdl-2.12.so
00000035c3c02000 2048 0 0 ----- libdl-2.12.so
00000035c3e02000 4 0 0 r---- libdl-2.12.so
00000035c3e03000 4 0 0 rw--- libdl-2.12.so
00000035c4000000 28 4 0 r-x-- librt-2.12.so
00000035c4007000 2044 0 0 ----- librt-2.12.so
00000035c4206000 4 4 4 r---- librt-2.12.so
00000035c4207000 4 0 0 rw--- librt-2.12.so
00000035c4400000 524 0 0 r-x-- libm-2.12.so
00000035c4483000 2044 0 0 ----- libm-2.12.so
00000035c4682000 4 4 4 r---- libm-2.12.so
00000035c4683000 4 4 4 rw--- libm-2.12.so
00000035c4800000 116 0 0 r-x-- libselinux.so.1
00000035c481d000 2044 0 0 ----- libselinux.so.1
00000035c4a1c000 4 0 0 r---- libselinux.so.1
00000035c4a1d000 4 0 0 rw--- libselinux.so.1
00000035c4a1e000 4 0 0 rw--- [ anon ]
00000035c5000000 12 0 0 r-x-- libcom_err.so.2.1
00000035c5003000 2044 0 0 ----- libcom_err.so.2.1
00000035c5202000 4 0 0 r---- libcom_err.so.2.1
00000035c5203000 4 0 0 rw--- libcom_err.so.2.1
00000035c5400000 88 0 0 r-x-- libresolv-2.12.so
00000035c5416000 2048 0 0 ----- libresolv-2.12.so
00000035c5616000 4 0 0 r---- libresolv-2.12.so
00000035c5617000 4 0 0 rw--- libresolv-2.12.so
00000035c5618000 8 0 0 rw--- [ anon ]
00000035c7000000 452 0 0 r-x-- libfreebl3.so
00000035c7071000 2044 0 0 ----- libfreebl3.so
00000035c7270000 8 0 0 r---- libfreebl3.so
00000035c7272000 4 0 0 rw--- libfreebl3.so
00000035c7273000 16 0 0 rw--- [ anon ]
00000035c7400000 28 0 0 r-x-- libcrypt-2.12.so
00000035c7407000 2048 0 0 ----- libcrypt-2.12.so
00000035c7607000 4 0 0 r---- libcrypt-2.12.so
00000035c7608000 4 0 0 rw--- libcrypt-2.12.so
00000035c7609000 184 0 0 rw--- [ anon ]
00000035c8800000 8 0 0 r-x-- libkeyutils.so.1.3
00000035c8802000 2044 0 0 ----- libkeyutils.so.1.3
00000035c8a01000 4 0 0 r---- libkeyutils.so.1.3
00000035c8a02000 4 0 0 rw--- libkeyutils.so.1.3
00000035c9800000 1764 72 0 r-x-- libcrypto.so.1.0.1e
00000035c99b9000 2044 0 0 ----- libcrypto.so.1.0.1e
00000035c9bb8000 108 4 0 r---- libcrypto.so.1.0.1e
00000035c9bd3000 48 12 12 rw--- libcrypto.so.1.0.1e
00000035c9bdf000 16 8 8 rw--- [ anon ]
0000003891400000 928 116 0 r-x-- libstdc++.so.6.0.13
00000038914e8000 2048 0 0 ----- libstdc++.so.6.0.13
00000038916e8000 28 20 12 r---- libstdc++.so.6.0.13
00000038916ef000 8 8 8 rw--- libstdc++.so.6.0.13
00000038916f1000 84 12 8 rw--- [ anon ]
0000003891800000 88 0 0 r-x-- libgcc_s-4.4.7-20120601.so.1
0000003891816000 2044 0 0 ----- libgcc_s-4.4.7-20120601.so.1
0000003891a15000 4 0 0 rw--- libgcc_s-4.4.7-20120601.so.1
0000003d4a800000 260 0 0 r-x-- libgssapi_krb5.so.2.2
0000003d4a841000 2048 0 0 ----- libgssapi_krb5.so.2.2
0000003d4aa41000 4 0 0 r---- libgssapi_krb5.so.2.2
0000003d4aa42000 8 0 0 rw--- libgssapi_krb5.so.2.2
0000003d4ac00000 164 0 0 r-x-- libk5crypto.so.3.1
0000003d4ac29000 2048 0 0 ----- libk5crypto.so.3.1
0000003d4ae29000 4 0 0 r---- libk5crypto.so.3.1
0000003d4ae2a000 4 0 0 rw--- libk5crypto.so.3.1
0000003d4ae2b000 4 0 0 rw--- [ anon ]
0000003d4b000000 40 0 0 r-x-- libkrb5support.so.0.1
0000003d4b00a000 2044 0 0 ----- libkrb5support.so.0.1
0000003d4b209000 4 0 0 r---- libkrb5support.so.0.1
0000003d4b20a000 4 0 0 rw--- libkrb5support.so.0.1
0000003d4b400000 392 0 0 r-x-- libssl.so.1.0.1e
0000003d4b462000 2044 0 0 ----- libssl.so.1.0.1e
0000003d4b661000 16 0 0 r---- libssl.so.1.0.1e
0000003d4b665000 28 4 4 rw--- libssl.so.1.0.1e
0000003d4b800000 876 0 0 r-x-- libkrb5.so.3.3
0000003d4b8db000 2044 0 0 ----- libkrb5.so.3.3
0000003d4bada000 40 0 0 r---- libkrb5.so.3.3
0000003d4bae4000 8 0 0 rw--- libkrb5.so.3.3
0000003f13600000 32 0 0 r-x-- libnuma.so.1
0000003f13608000 2048 0 0 ----- libnuma.so.1
0000003f13808000 4 4 4 rw--- libnuma.so.1
00007f46ddc00000 3776512 2380752 2380668 rw--- [ anon ]
00007f47c4639000 4 0 0 ----- [ anon ]
00007f47c463a000 256 24 24 rw--- [ anon ]
00007f47c467a000 4 0 0 ----- [ anon ]
00007f47c467b000 256 20 20 rw--- [ anon ]
00007f47c46bb000 4 0 0 ----- [ anon ]
00007f47c46bc000 256 120 120 rw--- [ anon ]
00007f47c46fc000 4 0 0 ----- [ anon ]
00007f47c46fd000 256 72 72 rw--- [ anon ]
00007f47c473d000 4 0 0 ----- [ anon ]
00007f47c473e000 256 72 72 rw--- [ anon ]
00007f47c477e000 4 0 0 ----- [ anon ]
00007f47c477f000 256 120 120 rw--- [ anon ]
00007f47c47bf000 4 0 0 ----- [ anon ]
00007f47c47c0000 225536 111736 111688 rw--- [ anon ]
00007f47d27bf000 4 0 0 ----- [ anon ]
00007f47d27c0000 53504 31016 31016 rw--- [ anon ]
00007f47d5fbf000 4 0 0 ----- [ anon ]
00007f47d5fc0000 16640 7868 7868 rw--- [ anon ]
00007f47d72bb000 4 0 0 ----- [ anon ]
00007f47d72bc000 256 120 120 rw--- [ anon ]
00007f47d72fc000 4 0 0 ----- [ anon ]
00007f47d72fd000 256 36 36 rw--- [ anon ]
00007f47d733d000 4 0 0 ----- [ anon ]
00007f47d733e000 256 56 56 rw--- [ anon ]
00007f47d737e000 4 0 0 ----- [ anon ]
00007f47d737f000 256 72 72 rw--- [ anon ]
00007f47d73bf000 4 0 0 ----- [ anon ]
00007f47d73c0000 61696 34148 34136 rw--- [ anon ]
00007f47db3bf000 4 0 0 ----- [ anon ]
00007f47db3c0000 16640 9692 9692 rw--- [ anon ]
00007f47dc7bf000 4 0 0 ----- [ anon ]
00007f47dc7c0000 16640 13124 13096 rw--- [ anon ]
00007f47dd838000 4 0 0 ----- [ anon ]
00007f47dd839000 256 120 120 rw--- [ anon ]
00007f47dd879000 4 0 0 ----- [ anon ]
00007f47dd87a000 256 20 20 rw--- [ anon ]
00007f47dd8ba000 4 0 0 ----- [ anon ]
00007f47dd8bb000 256 120 120 rw--- [ anon ]
00007f47dd8fb000 4 0 0 ----- [ anon ]
00007f47dd8fc000 256 116 116 rw--- [ anon ]
00007f47dd93c000 4 0 0 ----- [ anon ]
00007f47dd93d000 256 72 72 rw--- [ anon ]
00007f47dd97d000 4 0 0 ----- [ anon ]
00007f47dd97e000 256 84 84 rw--- [ anon ]
00007f47dd9be000 4 0 0 ----- [ anon ]
00007f47dd9bf000 256 120 120 rw--- [ anon ]
00007f47dd9ff000 4 0 0 ----- [ anon ]
00007f47dda00000 43008 17168 17140 rw--- [ anon ]
00007f47e0772000 4 0 0 ----- [ anon ]
00007f47e0773000 256 0 0 rw--- [ anon ]
00007f47e07b3000 4 0 0 ----- [ anon ]
00007f47e07b4000 256 0 0 rw--- [ anon ]
00007f47e07f4000 4 0 0 ----- [ anon ]
00007f47e07f5000 10240 0 0 rw--- [ anon ]
00007f47e11f5000 4 0 0 ----- [ anon ]
00007f47e11f6000 10240 8 8 rw--- [ anon ]
00007f47e1bf6000 4 0 0 ----- [ anon ]
00007f47e1bf7000 10240 36 36 rw--- [ anon ]
00007f47e25f7000 4 0 0 ----- [ anon ]
00007f47e25f8000 10240 0 0 rw--- [ anon ]
00007f47e2ff8000 4 0 0 ----- [ anon ]
00007f47e2ff9000 10240 24 24 rw--- [ anon ]
00007f47e39f9000 4 0 0 ----- [ anon ]
00007f47e39fa000 10240 24 24 rw--- [ anon ]
00007f47e43fa000 4 0 0 ----- [ anon ]
00007f47e43fb000 10240 28 28 rw--- [ anon ]
00007f47e4dfb000 4 0 0 ----- [ anon ]
00007f47e4dfc000 10240 20 20 rw--- [ anon ]
00007f47e57fc000 4 0 0 ----- [ anon ]
00007f47e57fd000 10240 12 12 rw--- [ anon ]
00007f47e61fd000 4 0 0 ----- [ anon ]
00007f47e61fe000 10240 8 8 rw--- [ anon ]
00007f47e6bfe000 4 0 0 ----- [ anon ]
00007f47e6bff000 10240 8 8 rw--- [ anon ]
00007f47e75ff000 4 0 0 ----- [ anon ]
00007f47e7600000 26624 10412 10284 rw--- [ anon ]
00007f47e93ff000 16388 13536 13516 rw--- [ anon ]
00007f47ea7f3000 4 0 0 ----- [ anon ]
00007f47ea7f4000 10240 8 8 rw--- [ anon ]
00007f47eb1f4000 4 0 0 ----- [ anon ]
00007f47eb1f5000 10240 16 16 rw--- [ anon ]
00007f47ebbf5000 4 0 0 ----- [ anon ]
00007f47ebbf6000 10240 8 8 rw--- [ anon ]
00007f47ec5f6000 4 0 0 ----- [ anon ]
00007f47ec5f7000 10240 8 8 rw--- [ anon ]
00007f47ecff7000 4 0 0 ----- [ anon ]
00007f47ecff8000 10240 8 8 rw--- [ anon ]
00007f47ed9f8000 4 0 0 ----- [ anon ]
00007f47ed9f9000 10240 8 8 rw--- [ anon ]
00007f47ee3f9000 4 0 0 ----- [ anon ]
00007f47ee3fa000 10240 16 16 rw--- [ anon ]
00007f47eedfa000 4 0 0 ----- [ anon ]
00007f47eedfb000 10240 24 24 rw--- [ anon ]
00007f47ef7fb000 4 0 0 ----- [ anon ]
00007f47ef7fc000 10240 16 16 rw--- [ anon ]
00007f47f01fc000 4 0 0 ----- [ anon ]
00007f47f01fd000 10240 24 24 rw--- [ anon ]
00007f47f0bfd000 4 0 0 ----- [ anon ]
00007f47f0bfe000 10240 8 8 rw--- [ anon ]
00007f47f15fe000 4 0 0 ----- [ anon ]
00007f47f15ff000 100356 49516 49484 rw--- [ anon ]
00007f47f7a00000 1107968 747476 745544 rw--- [ anon ]
00007f483b7f1000 4 0 0 ----- [ anon ]
00007f483b7f2000 10240 0 0 rw--- [ anon ]
00007f483c1f2000 48 0 0 r-x-- libnss_files-2.12.so
00007f483c1fe000 2048 0 0 ----- libnss_files-2.12.so
00007f483c3fe000 4 0 0 r---- libnss_files-2.12.so
00007f483c3ff000 4 0 0 rw--- libnss_files-2.12.so
00007f483c400000 4096 4096 4096 rw--- [ anon ]
00007f483c9ff000 4 0 0 ----- [ anon ]
00007f483ca00000 182272 57240 57208 rw--- [ anon ]
00007f4847d2f000 152 68 68 rw--- [ anon ]
00007f4847d55000 84 0 0 r-x-- libz.so.1.2.3
00007f4847d6a000 2044 0 0 ----- libz.so.1.2.3
00007f4847f69000 4 0 0 r---- libz.so.1.2.3
00007f4847f6a000 4 4 4 rw--- libz.so.1.2.3
00007f4847f6b000 12 4 4 rw--- [ anon ]
00007f4847f6f000 32 4 4 rw--- [ anon ]
00007f4847f77000 256 72 0 r-x-- libjemalloc.so.1
00007f4847fb7000 2048 0 0 ----- libjemalloc.so.1
00007f48481b7000 8 8 8 rw--- libjemalloc.so.1
00007f48481b9000 8 8 8 rw--- [ anon ]
00007ffffdd5c000 108 12 12 rw--- [ stack ]
00007ffffddff000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
---------------- ------ ------ ------
total kB 5971940 3496304 3488036

anon用途：'[ anon ]' for allocated memory，应该是glibc分配的内存。

一共有6列
第一列代表内存段的虚拟地址
第二列代表执行权限，r，w，x不必说，p=私有 s=共享
不用说，heap和stack段不应该有x，否则就容易被xx，不过这个跟具体的版本有关
第三列代表在进程地址里的偏移量
第四列映射文件的主设备号和次设备号
通过 cat /proc/devices
得知fd是253 device-mapper

第五列映像文件的节点号，即inode

第六列是映像文件的路径
以前我很奇怪怎么会有两个相同的文件路径，原来
08048000-08067000 r-xp 00000000 fd:00 843075     /sbin/init
08067000-08068000 rw-p 0001e000 fd:00 843075     /sbin/init
一个是只读的，是代码段，一个是读写的，是数据段

这个业务上基本山算是OLTP，盘中都是很简单的SQL，所以性能上虽然有些SQL有些慢，但看过slow-log和performance_schema，可以忽略不计。

初步了解，应用是java开发的，但是应用端没有出现过OOM的情况，也不见卡死或者越来越慢的情况。

从周一开始查到今天下午，尼玛mysql跟memory leak有关的几乎任何能够查到的buglist都被一个个review验证了，差不多能遇到的各种可能性都测试过，包括但不限于concat可能存在内存分配泄露，google版jemalloc可能导致内存增长，2.6.32版本vm.swappiness=0行为发生变化可能导致内存bug，mysql memory临时表释放可能存在问题，大量表的drop/create会导致dict_mem无限增长，几乎验证了mariadb/percona/mysql社区版本5.5,5.6,5.7各个版本，分析了各种mysql内存组成情况的脚本以及验证工具，尼玛都没找到问题。。。

尝试过将mysql 临时表从memory改到innodb，又改到myisam已验证可能存在问题，均没有发现明显问题。

有帖子又提及LOB可能会释放存在问题，仔细检查发现，业务表没有LOB类型，但似乎有定时任务不停在查询mysql.proc，需要跟开发确认原因。

某个帖子又提及5.0版本中client_statisitics中host超过16导致/tmp空间持续增长导致内存持续增长，我们用的percona server 5.6，经验证后，不是该问题所致。。不过顺带发现一个运维用python写的脚本不停地create/drop连接，要求整改了。。

线上环境基本上所有业务编写在存储过程中，一个过程套用其他五六个存储过程，各种奇葩逻辑。。。无奈只能做到运维旁边守着控制台盯着，已经排除了各种mysql服务器自身导致的问题，且验证了肯定不可能是innodb和其他服务器端可见的内存的问题之后，开始从应用程序入手，基本上连接就50个不到，有差不多一半的连接都是两个定时任务在实时更新风控相关的值，有数据更新程序就整个过程跑，不然就基本上跳过，里面使用了mysql临时表。没数据更新时虽然一直跑，但是mysql内存没有增长，到了盘中有数据之后，内存就每隔几秒nM到一二十M的增长，然后增长到了mysqld的内存占整个OS内存的90%左右，然后top RES维持在该值，VIRT开始继续增长，直到盘后的备份时因为OOM被os killed。盯着看了两天之后，本来昨天就打算在内存90%时逐台应用程序掐掉看下是不是客户端连接导致的，只是运维后来走了。。今天收市后让运维把接入机重启了下，瞬间mysqld内存占用回到了50%。问题的现状总算是可以重现了。

查看了下应用配置并跟框架确认了下，目前用的c3p0。

现在剩下的就是明天继续盯盘检查时c3p0连接配置问题所致，还是mysql临时表问题（在测试环境各个版本都模拟了，都没重现线上问题，估计不是这个问题所致是大概率），要是还不是这两个问题所致， 只能代码慢慢debug优化下去，然后再找到根本原因。

。。。严重吐槽。。。

mysql查看innodb/myisam之外内存使用情况的工具基本上没有。网上的各种什么mysqltuner.pl，my_memory，包括mysql 5.7的memory performance_schema，各种的瞎猜测。。

唯一可靠的估计就是valgrind，可惜没法attach到线上进程。。

周五继续跟踪了下，不是mysql临时表的原因，大概确定为mysql 存储过程 最后返回结果给jdbc客户端时使用了select * from ...的原因，纯粹的存储过程select并没有这个问题，这个使用mysqlslap跑了几千万次验证过。这两天具体测试是否这原因所致。

问题现在已经初步解决：应用端jdbc连接池的minIdle默认值降低，不和maxActive相同。并加上testOnBorrow=true。下午跟踪下来内存在达到65%之后，基本上不再上升，innodb大概实际使用了1.5g，最多40个并发连接左右最高触及2.4g之后基本上没有在上升，mysql进程占用的内存在56%到65%之间波动。

业务结束后调整增加minEvictableIdleTimeMillis，timeBetweenEvictionRunsMilis参数，minIdle设置为1，明后天再观察两天，确保库的稳定。

PS: mariadb 10.0.2开始，show processlist有个额外的列memory_used，可查看每个进程的内存占用。