平均负载高并不直接等同于系统卡顿，优化前必须先确认负载来源是 CPU 计算还是磁盘 I/O 等待，盲目调整内核参数往往无效。
先说结论：负载高只是现象，核心是找到占用资源的进程及其状态，针对性调整优先级或解决 I/O 瓶颈。
- 先定位：区分是 CPU 密集型还是 I/O 等待导致的负载堆积
- 先做：优先调整进程优先级或限制资源，而非直接重启服务
- 再验证：观察负载趋势及应用响应延迟，确认优化无副作用
命令速用版
uptime # 查看负载概览
sudo top -H -p <PID> # 查看指定进程的线程负载
vmstat 1 # 查看 CPU 与 IO 等待
sudo pidstat -d 1 # 查看进程 IO 统计
sudo iotop -oP # 实时查看 IO 占用进程为什么会这样
Linux 的平均负载（Load Average）统计的是处于“可运行状态”和“不可中断睡眠状态”的进程数。很多人误以为负载高就是 CPU 忙，但实际上如果大量进程卡在磁盘 I/O 等待（D 状态），负载也会升高，此时 CPU 使用率可能很低。
因此，看到负载高就增加 CPU 核心数或调整 CPU 调度参数，往往无法解决 I/O 瓶颈问题，甚至可能因为上下文切换增加而恶化性能。
分步处理
1. 确认负载与核心数的关系
使用
nproc查看逻辑核心数。如果 1 分钟负载值超过核心数，说明有进程在排队。例如 4 核机器负载为 8，意味着平均有 4 个进程在等待。
2. 识别进程状态与定位源头
首先使用
top观察顶部的 CPU 行，关注
wa（iowait）百分比。如果 wa 较高，说明瓶颈在磁盘或网络 IO；如果 us（用户态）或 sy（内核态）高，说明是计算密集。
若确认为 IO 问题，需进一步定位具体进程。推荐使用
sudo iotop -oP直接查看实际产生 IO 的进程列表。或者使用
sudo pidstat -d 1观察每个进程的 kB_rd/s 和 kB_wr/s，找出 IO 读写最高的 PID。
3. 调整进程优先级
对于非关键业务进程，可以降低其优先级，让出资源给关键业务。注意以下命令通常需要 root 权限：
sudo renice -n 10 -p <PID> # 降低 CPU 调度优先级如果是 IO 密集进程，可以使用
sudo ionice -c 3 -p <PID> # 将 IO 优先级设为最低4. 限制资源使用
如果是某个服务失控，建议使用 cgroups 或 systemd 限制其 CPU 或 IO 权重，而不是直接 kill。例如在 systemd 中编辑服务文件，添加
IOWeight=100修改配置后，必须重载配置并重启服务才能生效：
sudo systemctl daemon-reload
sudo systemctl restart <service>怎么验证是否生效
执行优化后，持续运行
vmstat 1观察
r列（运行队列）是否下降，以及
wa列是否恢复正常。同时监控业务接口的响应时间，确保负载下降没有导致关键业务变慢。
常见坑
- 盲目杀进程：直接 kill 高负载进程可能导致数据不一致或业务中断，应先尝试降级或限流。
- 忽视 D 状态进程：处于不可中断睡眠的进程无法被 kill，通常由驱动或内核问题引起，需检查系统日志。
- 随意调整内核参数：如 vm.swappiness 等参数需结合内存使用情况，默认值通常适用于大多数场景，随意修改可能引发交换抖动。
- 权限不足：renice、ionice 及查看进程详细 IO 信息通常需要 sudo 权限，普通用户执行会失败。
原文链接：https://www.zjcp.cc/ask/10906.html