报警描述

业务[XX业务],虚拟机[X.X.X.X]内存-OOM状态报警,状态为剩余内存逼近内存水位底线

说明

监控对象

Linux操作系统。

监控方式

Linux

检测脚本如下

#!/bin/bashmin_free=`cat /proc/sys/vm/min_free_kbytes`
cur_free=`vmstat |grep -v procs|grep -v swpd|awk '{print$4}'`echo "MIN=$min_free"echo "CUR=$cur_free"for proc in $(find /proc -maxdepth 1 -regex '/proc/[0-9]+'); do
    printf "OOM=%d,%d\n" \        "$(cat $proc/oom_score)" \        "$(basename $proc)"done

输出

MIN=67584
CUR=1033328
OOM=0,1
OOM=0,2
OOM=0,3
OOM=0,5
OOM=0,7
OOM=0,8
OOM=0,9
OOM=0,10
OOM=0,11
OOM=0,12
...
OOM=0,82308
OOM=0,82314
OOM=0,82318
OOM=0,82330
OOM=0,83822
OOM=0,83989
OOM=0,84026
OOM=0,84131
OOM=0,84198
OOM=0,84205

这里采用命令输出中的MIN和CUR的值进行计算。
MIN是内存OOM的最低水位线，CUR是当前剩余内存的数量。当剩余内存逼近OOM最低水位线时，触发报警。

规则

默认为报警级别。

案例

技术：这个是根据剩余内存判断的，就是free -g 中的free值。这个数值跟 /proc/sys/vm/min_free_kbytes 配置的水位线比较，如果低于1.5倍的关系，就会报警了。对于这台服务器，水位线的值是 225280 ，即225MB，free内存400MB上下，偶尔触及330 MB，就会报警了。如果剩余内存低于 225MB，就会触发kswapd0 进程进行内存回收，导致系统卡顿，并根据评分杀死占用内存的进程。如果杀死的是数据库或应用的进程，应用就无法访问了。

客户：这个服务器只有一个数据库在运行我是不是把水位线增加了就没问题了？

技术：不是，水位线增加，这种情况会更严重。

技术：这个机器如果只有数据库的话，应该是mysql把内存都用来缓存数据了，free里面看也是cache较高，大约占了14G左右。到达水位线附近的时候，系统会优先释放cache，如果内存不够，再根据评分杀死进程。所以对这台机器，我觉得可以先不进行优化，可以忽略掉报警。

客户：嗯嗯好的麻烦帮我设置忽略一下吧

技术：如果确实出现卡顿情况，建议优先考虑提高内存总量，而不是根据参数优化。

客户：接口查询数据不会特别大不会卡顿，只有每半点儿同步号源是会大量io 平时用户访问量都是些挂号查工牌看工号的这些。

参考

https://blog.csdn.net/weixin_32539505/article/details/114327193