【OS】自建MYSQL服务器OOM分析思路
【背景描述】
从自建MYSQL数据库发生OOM的案例分析出多种因素,但大部分OOM都可以从日志和内存报错相关方向来着手寻找原因,再根据线索来梳理优化思路。
【环境说明】
数据库:MYSQL5.7
系统版本:CentOS 7
【分析过程】:
一:查看日志和资源使用量(默认日志在/var/log/messages)
1.服务器物理内存相对热点数据文件可能偏小
从日志(见上图)看触发OOM是binlog备份的cp进程。
2.查看实例物理内存使用量对比
(1)实例1(见下图)配置了45G的buffer pool,发生OOM时,mysqld进程实际使用到约60G左右。
(2)实例2(见下图)配了32G的buffer pool,物理内存用到了57G,SWAP使用5G左右。
结论:实际使用物理内存远大于innodb_buffer_pool_size设置。
3.列举系统上的NUMA节点信息:
Numastat –c qemu-kvm
总结: NUMA节点(见上图)内存分配不均导致了SWAP空间大量使用,上图是这台服务器mysqld进程在各NUMA节点的内存使用情况。
建议:1.在运行mysql服务的服务器上一般只会部署mysql一种服务在运行,而不会部署若干应用运行。mysql是独占整个服务器的资源,所以不建议开启numa内存特性。因为这种特性很容易引起内存泄漏的情况,即发现物理内存还有剩余,但是系统已经开始使用swap内存。
2.如果numa内存分配不均,会导致SWAP的大量占用,有可能会导致服务器发生OOM,也可以开启numa interleave访问。
二:开启和关闭NUMA
1.开启numa interleave步骤
(1)安装numactl工具:
yum install numactl -y
(2)修改/usr/bin/mysqld_safe文件:
cmd="`mysqld_ld_preload_text`$NOHUP_NICENESS"下新增一条脚本
cmd="/usr/bin/numactl --interleave all $cmd"
(3)停止服务:
service mysql stop
(4)写入硬盘,防止数据丢失:
sync;sync;sync
(5)延迟10秒:
sleep 10
(6)清理pagecache、dentries和inodes:
Sysctl -q -w vm.drop_caches=3
(7)开启服务:
service mysql start
(8)验证numactl –interleave all是否生效:
可以通过下面命令,interleave_hit是采用interleave策略从该节点分配的次数, 没有启动interleave策略的服务器,这个值会很低。
numastat -mn -p `pid of mysqld`
或者可参考:https://blog.csdn.net/weixin_36296325/article/details/114321385
2.关闭NUMA的步骤
(1)BIOS层面:
BIOS:interleave = Disable / Enable
由于不同系统之间各种BIOS类型的区别可能设置各有不同。
(2)操作系统层面:
可以直接在/etc/grub.conf的kernel行最后添加numa=off。
(3)MySQL层面:
直接修改启动脚本:
numactl --interleave=all mysqld --defaults-file=/etc/my.cnf &
(4)设置innodb_numa_interleave参数:
MySQL5.7.9版本+,新增了参数innodb_numa_interleave。根据官方文档的描述:当设置innodb_numa_interleave=1的时候,对于mysqld进程的numa内存分配策略设置为MPOL_INTERLEAVE,而一旦Innodb buffer pool分配完毕,则策略重新设置回MPOL_DEFAULT。当然这个参数是否生效,必须建立在mysql是在支持numa特性的linux系统上编译的基础上。
在MySQL5.7.17版本+, CMake编译软件新增了WITH_NUMA参数,可以在支持numa特性的linux系统上编译mysql。
(5) 查看关闭情况
MySQL 5.6.27/5.7.9开始引用innodb_numa_interleave选项。可能根据不同系统和版本方法略有不同,本文旨在提供思路。
- 点赞
- 收藏
- 关注作者
评论(0)