共计 1726 个字符，预计需要花费 5 分钟才能阅读完成。
背景: 收到内存报警的信息以后, 从监控中发现 MySQL 服务器的内存使用率在不断的增长;
附图:
虽然进行了重启, 但是内存占用率依然会不停的增长, 大约在半个月左右的时间内又把内存消耗完毕;
场景: 未搭建场景, 数据库版本 5.7.12
分析:
PS: 时间久远, 截图仅做分析 / 示例所用, 不一定是当时候出问题时的数据
尝试方向 1:
首先考虑的是 buffer 相关的参数是否设置有误, 毕竟当初 crash 的时候曾经出现过类似的问题 (http://www.linuxidc.com/Linux/2016-12/137853.htm)
结果: 参数设置都没什么明显的问题;
尝试方向 2:
既然设置没什么问题, 那就看一下内存的占用情况吧~
使用 pmap -d 看一下进程的内存情况; 部分信息截图如下
anon 代表进程主动申请的内存, 当时对有问题的机器进行统计时, 发现主动申请的内存占了进程内存的 95%(当然的.. 因为 buffer 都在这里面)
考虑到 innodb_buffer_pool 的大小只有总内存的 50%, 多出来的这些 ” 已申请 ” 的内存实在是有点太多了, 是不是有什么线程申请了大量的内存没有释放?
尝试方向 2 – 检查线程的内存使用:
MySQL5.7 中对 ps(performance_schema)进行了拓展, 能统计更多的数据了, 这其中就包括了有关 mem 的信息;
由于默认是关闭的, 所以现在要临时打开这些统计数据;
1. 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;
官方给出的解决方案是关闭并行复制, 并且把 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: 到目前为止, 出问题的个别实例都没有再增长到非常高的地步, 目测需要两个多月才可能会维护 (重启) 一次;
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-12/137852.htm
