拖了好久了, 抽空补上_(:з」∠)_
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
背景: 收到内存报警的信息以后, 从监控中发现MySQL服务器的内存使用率在不断的增长;
附图:
虽然进行了重启, 但是内存占用率依然会不停的增长,大约在半个月左右的时间内又把内存消耗完毕;
场景: 未搭建场景, 数据库版本 5.7.12
分析:
PS: 时间久远,截图仅做分析/示例所用, 不一定是当时候出问题时的数据
尝试方向1:
首先考虑的是buffer相关的参数是否设置有误, 毕竟当初crash的时候曾经出现过类似的问题(http://blog.itpub.net/29510932/viewspace-2123096/)
结果: 参数设置都没什么明显的问题;
尝试方向2:
既然设置没什么问题, 那就看一下内存的占用情况吧~
使用pmap -d看一下进程的内存情况; 部分信息截图如下
anon代表进程主动申请的内存,当时对有问题的机器进行统计时, 发现主动申请的内存占了进程内存的95%(当然的..因为buffer都在这里面)
考虑到innodb_buffer_pool的大小只有总内存的50%,多出来的这些"已申请"的内存实在是有点太多了, 是不是有什么线程申请了大量的内存没有释放?
尝试方向2--检查线程的内存使用:
MySQL5.7中对ps(performance_schema)进行了拓展, 能统计更多的数据了, 这其中就包括了有关mem的信息;
由于默认是关闭的, 所以现在要临时打开这些统计数据;
点击(此处)折叠或打开
update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%'
执行上述语句之后, 在ps里面就能在mem相关的表里面看到相关的统计信息了; 如下图:
其中CURRENT_NUMBER_OF_BYTES_USED可以近似的当成目前占用的内存总数;
PS: 由于这个统计信息并不会区分共享内存,所以有可能会出现占用内存为负数, 或者各个项的总和大于实际占用内存总数;
由于是怀疑线程, 所以用CURRENT_NUMBER_OF_BYTES_USED倒序, 查询Thread相关的表; 结果类似下图:
当时有问题的实例中, 查询结果结合ps.thread表数据,显示thread/sql/slave_sql和thread/sql/one_connection(monitor用户)的内存占用非常高~
尝试方向2--分析线程:
thread/sql/slave_sql是同步中的SQL线程,负责复现主库binlog中的事务, 这个线程占用大量内存却不进行释放的现象, 第一反应不是我们自己的问题;
在mysql bug上面找了一圈,发现以前有人提交了类似的bug(https://bugs.mysql.com/bug.php?id=71197), 状态为close;
官方给出的解决方案是关闭并行复制, 并且把