平均负载高并不直接等同于系统卡顿，优化前必须先确认负载来源是 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 权限，普通用户执行会失败。