MySQL服务器发生OOM的案例分析

【问题】

有一台MySQL5.6.21的服务器发生OOM,分析下来与多种因素有关

【分析过程】

1服务器物理内存相对热点数据文件偏小,62G物理内存+8G的SWAP,数据文件大小约550G

 触发OOM是binlog备份的cp进程

2、mysqld实际使用物理内存远大于innodb_buffer_pool_size设置,与我们之前分析的内存分配管理模块有关,建议更换为jemalloc

可以参考我之前的文章,MySQL5.7.18(ptmalloc VS tcmalloc VS jemalloc)性能测试

<1>这个MySQL实例配置了45G的buffer pool,发生OOM时,mysqld进程实际使用到约61G

 

<2>另一台相同配置的服务器,配了32G的buffer pool,MySQL物理内存用到了57G,SWAP已使用5G

3、NUMA节点内存分配不均导致了SWAP空间大量使用,下图是这台服务器mysqld进程在各NUMA节点的内存使用情况,建议开启numa interleave访问

 

【优化方案】

1、 升级内存更大的服务器

2、 建议更换mysqld进程的内存分配管理模块为jemalloc

3、 建议开启mysql进程的numa  interleave访问

开启numa  interleave的步骤,可以参考文章

NUMA导致的MySQL服务器SWAP问题分析与解决方案

原文地址:https://www.cnblogs.com/wangdong/p/9850802.html