首页 ›存档› 技术 › 查看内容

MySQL案例-内存使用率无限增长

2018-3-30 13:00 |来自: 互联网 988 0

摘要: 点击上方“蓝字”可以关注我们哦 |本文来自：ITPUB博客 |作者：wangwenan6 |原文链接：http://blog.itpub.net/29510932/viewspace-2129312/ 背景: 收到内存报警的信息以后, 从监控中发现MySQL服务器的内存使用率在 ...

点击上方“蓝字”可以关注我们哦

|本文来自：ITPUB博客

|作者：wangwenan6

|原文链接：http://blog.itpub.net/29510932/viewspace-2129312/

背景: 收到内存报警的信息以后, 从监控中发现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;

官方给出的解决方案是关闭并行复制, 并且把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: 到目前为止, 出问题的个别实例都没有再增长到非常高的地步, 目测需要两个多月才可能会维护(重启)一次;

我知道一种学习

○

于坚

声明：文章版权归原作者所有部分文章转自互联网如有侵权请联系 [邮箱地址] 删除