经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » MySQL » 查看文章
分享MySQL生产库内存异常增高的排查过程
来源:jb51  时间:2022/4/11 8:45:03  对本文有异议

    近期频繁收到一个MySQL实例的内存使用率高的报警,今天我们花时间排查一下问题出在哪里。

修改performance_schema

因为公司生产环境使用的阿里云RDS,修改参数相对方便,performance_schema默认为0,此次修改为1。修改之后提交参数,数据库会进行重启,建议在业务低峰进行。

打开内存监控

登录MySQL数据库,执行如下SQL,打开内存监控。

  1. update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';

打开之后验证一下。

  1. select * from performance_schema.setup_instruments where name like 'memory%innodb%' limit 5;
  2.  

**注意:**该命令是在线打开内存统计,所以只会统计打开后新增的内存对象,打开前的内存对象不会统计,建议您打开后等待一段时间再执行后续步骤,便于找出内存使用高的线程。

查找内存消耗

统计事件消耗内存

  1. select event_name,
  2. SUM_NUMBER_OF_BYTES_ALLOC
  3. from performance_schema.memory_summary_global_by_event_name
  4. order by SUM_NUMBER_OF_BYTES_ALLOC desc
  5. LIMIT 10;
  6. +---------------------------------------+-------------------------------------+
  7. | event_name | SUM_NUMBER_OF_BYTES_ALLOC |
  8. +---------------------------------------+-------------------------------------+
  9. | memory/sql/Filesort_buffer::sort_keys | 763523904056 |
  10. | memory/memory/HP_PTRS | 118017336096 |
  11. | memory/sql/thd::main_mem_root | 114026214600 |
  12. | memory/mysys/IO_CACHE | 59723548888 |
  13. | memory/sql/QUICK_RANGE_SELECT::alloc | 14381459680 |
  14. | memory/sql/test_quick_select | 12859304736 |
  15. | memory/innodb/mem0mem | 7607681148 |
  16. | memory/sql/String::value | 1405409537 |
  17. | memory/sql/TABLE | 1117918354 |
  18. | memory/innodb/btr0sea | 984013872 |
  19. +---------------------------------------+-------------------------------------+

可以看到内存消耗最高的event是Filesort_buffer,根据经验,这个应该是排序有关。

统计线程消耗内存

  1. select thread_id,
  2. event_name,
  3. SUM_NUMBER_OF_BYTES_ALLOC
  4. from performance_schema.memory_summary_by_thread_by_event_name
  5. order by SUM_NUMBER_OF_BYTES_ALLOC desc
  6. limit 10;
  7. +---------------------+---------------------------------------+-------------------------------------+
  8. | thread_id | event_name | SUM_NUMBER_OF_BYTES_ALLOC |
  9. +---------------------+---------------------------------------+-------------------------------------+
  10. | 105 | memory/memory/HP_PTRS | 69680198792 |
  11. | 183 | memory/sql/Filesort_buffer::sort_keys | 49210098808 |
  12. | 154 | memory/sql/Filesort_buffer::sort_keys | 43304339072 |
  13. | 217 | memory/sql/Filesort_buffer::sort_keys | 37752275360 |
  14. | 2773 | memory/sql/Filesort_buffer::sort_keys | 31460644712 |
  15. | 218 | memory/sql/Filesort_buffer::sort_keys | 31128994280 |
  16. | 2331 | memory/sql/Filesort_buffer::sort_keys | 28763981248 |
  17. | 106 | memory/memory/HP_PTRS | 27938197584 |
  18. | 191 | memory/sql/Filesort_buffer::sort_keys | 27701610224 |
  19. | 179 | memory/sql/Filesort_buffer::sort_keys | 25624723968 |
  20. +---------------------+---------------------------------------+-------------------------------------+

可以看到内存消耗多的线程都跟Filesort_buffer相关。

定位具体SQL

根据前边我们查到的thread_id去日志里查找对应的SQL,阿里云RDS审计日志相对还是比较强大的。我们直接根据thread_id直接检索。

记一次MySQL生产库内存异常增高的排查过程_MySQL

    我们在日志里看到大量这样的SQL,扫描行数在几千到几万不等。虽然每次查询时间并不长,大概在几十到几百毫秒,但是并发量很大。
    跟开发同学核实之后,这个查询没有做分页,取到的数据有很多行,而且最后要做排序,并且排序字段并没有合适的索引。到此,这次内存使用率出现异常的罪魁祸首已经找到。

到此这篇关于分享MySQL生产库内存异常增高的排查过程的文章就介绍到这了,更多相关MySQL生产库内存异常增高内容请搜索w3xue以前的文章或继续浏览下面的相关文章希望大家以后多多支持w3xue!

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号