Linux 系统负载居高不下排查手册

系统负载高，不等于 CPU 已经跑满。很多运维同学一看到 load average 飙到几十就急着扩容或重启，结果问题依旧，甚至把真正的原因掩盖了。本文给出一套可复用的排查手册：先定性，再定位，最后处理和预防。

一、先看三个数，别只看一个

uptime
cat /proc/loadavg
nproc

load average 的三个数分别代表 1 分钟、5 分钟、15 分钟内处于运行态和不可中断睡眠态的进程平均数。它不是百分比，必须和 CPU 核数一起看：4 核机器上 load 为 4，基本是满载；32 核机器上 load 为 8，可能还很轻松。还要看趋势：1 分钟高、15 分钟低，多半是突发任务；三个数一起爬升，才是持续性压力。

同时用 vmstat 1 5 看 r 列、b 列、us、sy、wa、id。r 持续大于核数说明 CPU 排队；b 持续大于 0 说明有进程在等 IO；wa 高则要优先查磁盘。

二、用 top 和 ps 区分三类负载

top -b -n 1 | head -20
ps aux --sort=-%cpu | head -20
ps -eo pid,ppid,stat,%cpu,%mem,cmd --sort=-%cpu | head -20

第一类是 CPU 型：top 里 %CPU 长期居高，us 或 sy 占比大，常见于死循环、正则回溯、未限流的批量计算、单线程热点。这时先看具体进程和线程，再看它在做什么，而不是先加核。

top -H -p <PID>
pidstat -u -t 1 5
cat /proc/<PID>/status | grep -E 'Threads|VmRSS'

第二类是 IO 等待型：CPU 空闲 id 并不低，但 wa 高、load 高。先用 iostat -x 1 5 看 await、%util 和具体磁盘，再用 iotop -oPa 或 pidstat -d 1 找到读写大户。日志刷盘、备份、全表扫描、磁盘接近写满都可能表现为这种形态。

第三类是不可中断睡眠（D 状态）：进程在等磁盘、网络文件系统或驱动，信号也杀不掉。ps 里 STAT 出现 D，同时 b 列升高，就是典型信号。此时不要反复 kill -9，先查 dmesg、磁盘健康和挂载状态：

ps -eo pid,stat,cmd | awk '$2 ~ /D/'
dmesg -T | tail -50
lsblk -f; df -h; mount | grep -E 'nfs|dead'

三、常见根因与处理步骤

1. 定时任务扎堆：备份、报表、爬虫、清理脚本同时在整点启动。查 crontab -l、systemd timer 和业务调度，把任务错峰，必要时加锁防止重复执行。
2. 失控进程或线程泄漏：线程数持续增长、内存同步上涨。先用 renice 或 cgroup 限流保住线上，再抓线程栈和日志复现，修复后灰度验证。
3. 磁盘瓶颈：先确认是读多还是写多，再看是单盘慢还是阵列慢。临时措施包括错开备份、降低日志级别、清理无用文件；长期措施是换更快的盘、做读写分离或加缓存。
4. 锁与等待：数据库慢查询、分布式锁超时、NFS 挂死都会让大量进程排队。用慢日志和链路日志找到等待源头，而不是只重启应用。

处理时坚持先止血后根治：能限流就不限量重启，能隔离就不要全量停服；每一步只改一个变量，并记录改动前后的 load、CPU、wa 数值，方便回滚。

四、预防建议

把 load、CPU、iowait、磁盘 await、D 状态进程数、线程数一起接入监控，设置分级告警：短时突刺只提醒，持续 10 分钟以上才升级。对备份、批量任务做资源配额和错峰窗口，关键服务做 CPU 与 IO 隔离。每月复盘一次高负载事件，沉淀成检查清单，下次告警响起时按清单走，就不会再凭感觉扩容或重启了。