拖了好久了, 抽空补上 _(:з」∠)_
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
背景: 收到内存报警的信息以后, 从监控中发现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的信息;
由于默认是关闭的, 所以现在要临时打开这些统计数据;
执行上述语句之后, 在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;
官方给出的解决方案是关闭并行复制, 并且把 rpl相关的信息存在file里面, 而不是table;
PS: Nice! 那5.7弄个并行复制不是坑自己么...... _(:з」∠)_
thread/sql/one_connection(monitor用户)是由用户创建的, 可以发现是monitor用户保持的连接, 主要用于自维护的监控插件获取信息的;
这个至少是能想办法解决的, 那么看一下monitor线程的详细信息:
查看以后发现memory/sql/String::value占用的内存数最多;
从字面意思理解, 似乎是执行的SQL有点问题, 保存了大量的结果没有释放?
联系了插件的编写人员, 找到插件的代码, 仔细看了一圈, 发现代码在使用cursor执行SQL以后, 没有close......
对代码进行fix及推送以后, 内存使用率的增长速度大幅度降低了;
处理结果:
把这个没有close的经典问题挂到了内部的文档里面作为反例.......
然后由于一些原因, SQL线程无法释放已占用内存的问题无法解决, 好在增长的速度并不快, 还在可接受的范围之内, 暂时做好定期维护(重启)的准备;
PS: 到目前为止, 出问题的个别实例都没有再增长到非常高的地步, 目测需要两个多月才可能会维护(重启)一次;
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
背景: 收到内存报警的信息以后, 从监控中发现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%'
其中 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;
官方给出的解决方案是关闭并行复制, 并且把 rpl相关的信息存在file里面, 而不是table;
PS: Nice! 那5.7弄个并行复制不是坑自己么...... _(:з」∠)_
thread/sql/one_connection(monitor用户)是由用户创建的, 可以发现是monitor用户保持的连接, 主要用于自维护的监控插件获取信息的;
这个至少是能想办法解决的, 那么看一下monitor线程的详细信息:
查看以后发现memory/sql/String::value占用的内存数最多;
从字面意思理解, 似乎是执行的SQL有点问题, 保存了大量的结果没有释放?
联系了插件的编写人员, 找到插件的代码, 仔细看了一圈, 发现代码在使用cursor执行SQL以后, 没有close......
对代码进行fix及推送以后, 内存使用率的增长速度大幅度降低了;
处理结果:
把这个没有close的经典问题挂到了内部的文档里面作为反例.......
然后由于一些原因, SQL线程无法释放已占用内存的问题无法解决, 好在增长的速度并不快, 还在可接受的范围之内, 暂时做好定期维护(重启)的准备;
PS: 到目前为止, 出问题的个别实例都没有再增长到非常高的地步, 目测需要两个多月才可能会维护(重启)一次;
