数据库的运维工作中，可能经常碰到主机负载高的场景，但是负载高，未必都是数据库的问题，还是要具体问题具体分析。技术社群的这篇文章《故障分析 | 数据库主机负载高一例分析》就给出了一个这样的场景。
1故障现象
机器负载很高，持续一段时间负载值约 85，当前主机为 10 核，每核 2 个线程，短期的监控数据表明负载无明显波动。
将监控数据周期拉长到 3 个月，可以看到负载是慢慢的上升趋势，尾部出现拐点，负载直线下降是故障解决后效果。
CPU 空闲率趋势也无明显波动，空闲率约 60%。
磁盘 IO 繁忙率趋势也无明显波动，繁忙率还是比较高的。
内存使用率不高，也无明显波动，故障解决后有少许降低。
2故障分析
通过监控图看不出什么问题，从 DB 层观察也无明显异常，登录执行 top 命令，没有消耗资源特别高的进程，但是发现了以下异常：
系统 CPU 使用率较高
系统 CPU 使用率达到约 20%。从监控图看 5 月 14 号以后系统 CPU 使用率突然飙高，尾部拐点也是优化后效果。
异常进程
top 命令中发现了 df 命令进程。一般 df 命令都是快速返回结果，很难在 top 中发现的，于是手工执行 df 命令，竟然卡住了，也退不出来。
根据经验这应该是挂载了 NFS 文件系统，NFS Server 端连不上了。查看 /etc/fstab，使用了 NFS 文件系统 /backup；umount 卸载报设备繁忙；fuser -m -v 发现了一堆进程在使用 NFS。
找了几个进程，kill -9 还杀不掉，umount -l 先将文件系统惰性卸载掉了，再慢慢地清理了这些卡死进程后负载从 80 降到了 10。
这里还遗留了第一个问题，为何系统 CPU 使用率达到 20%？
使用 atop 发现，默认的 10s 周期 #exit 值达到了 2w。说明短期内创建了大量短时进程，系统调用繁忙，导致系统 CPU 比较高，进程中发现了 Zabbix 用户，DB 层没有问题，可疑用户就是 Zabbix 了，通过简单循环跟踪 Zabbix 用户的进程。
while true;do ps -ef|grep zabbix;sleep 2;done;发现了某一自动发现原型监控项多达 1000+。
1000+ 并发方式调用脚本去获取监控项数据，每 30s 执行一次，显然监控方式存在问题，需要优化，将该监控项停掉后，系统 CPU 使用率从 20% 下降到不到 2%。
3因此
从系统负载高还意外收获了 SYS CPU 使用率高，本次负载高跟以往的情况不同，是一点一点慢慢的上去的，同时 CPU/MEMORY/IO 并无明显波动趋势，需要结合各种监控工具仔细观察及分析。
如果您认为这篇文章有些帮助，还请不吝点下文章末尾的"点赞"
