# 找到资源瓶颈：进程、负载与 IO

Load Average 是一段时间内任务负载的指标，不能直接当成 CPU 百分比。应结合 CPU 核数、内存和磁盘等待分析。

更新日期：2026-09-16

规范地址：https://stock.iftalking.com/guides/process-monitoring/

## 1. 先判断 CPU、内存还是 I/O 在忙

实例面板中的 Load Average 是一段时间内可运行或处于不可中断等待状态的任务数量，不是 CPU 使用百分比。单核机器负载 4 与八核机器负载 4 的含义不同；磁盘等待也可能推高负载。

![面板中的运行状态和负载入口](https://stock.iftalking.com/tutorial-media/provider-kiwivm-overview.jpg)

*图示说明：服务商官方知识库公开截图（旧版界面），用于对照功能名称；当前菜单位置可能调整。图中的套餐、IP、端口和日期仅为示例。*

```bash
uptime
nproc
free -h
vmstat 1 10
```

`vmstat` 第一行常是启动以来的平均值，后续才是采样间隔的数据。观察 r（等待 CPU 的任务）、wa（I/O 等待）、si/so（Swap 活动），再选择下一步工具。

## 2. 用 top/htop 找到具体进程

```bash
top
ps -eo pid,ppid,user,%cpu,%mem,etime,comm --sort=-%cpu | head -20
```

top 可按 P 以 CPU 排序、M 以内存排序，按 q 退出。htop 提供更直观的列表，可从发行版软件源安装。先记录 PID、进程名、所属用户和运行时长，再查它属于哪个服务，不要只看到占用高就结束进程。

短时间编译、压缩或数据库导入可能合理占用 CPU；长时间重复重启、请求暴增或内存持续增长则值得调查。

## 3. 用服务日志解释资源变化

```bash
systemctl --failed
systemctl status nginx
sudo journalctl -u nginx --since '30 minutes ago' --no-pager
```

把 `nginx` 换成实际服务。日志时间应与监控异常时间对应；数据库慢查询、应用报错、反复连接失败都可能解释 CPU 或内存峰值。日志可能包含访问令牌和用户数据，分享前先脱敏。

需要更细的历史采样时，可安装 sysstat，并按发行版设置启用采集。`iostat -xz 1 5` 查看磁盘延迟与利用情况，`pidstat 1 5` 查看进程采样。虚拟磁盘的统计要结合应用等待时间解释，不能仅凭一个 %util 数字断言宿主机故障。

## 4. 处理异常时先正常停止

有 systemd 管理的程序，先使用 `systemctl stop 服务名`；普通进程先发 TERM，让它有机会保存状态。只有确认无法正常退出且理解影响时，才考虑 KILL。数据库或正在写备份的进程被强制终止，可能需要额外恢复。

如果异常来自定时任务，检查是否重叠运行；来自网站访问，检查是否需要缓存、速率限制或减少并发。限制 CPU 可以控制资源，但不能修复无限循环或内存泄漏。

## 5. 修复后观察一段完整业务周期

记录处理前后的 CPU、available 内存、磁盘延迟和请求响应时间。至少覆盖一次原来容易出问题的时段，确认不是仅因为流量暂时下降而恢复。

下一步可按瓶颈阅读[内存与 Swap](https://stock.iftalking.com/guides/memory-swap/)、[磁盘清理](https://stock.iftalking.com/guides/disk-cleanup/)、[后台任务管理](https://stock.iftalking.com/guides/persistent-jobs/)或[WordPress 性能优化](https://stock.iftalking.com/guides/wordpress-performance/)。


## 完成后检查

不要只截一张空闲时的面板图判断性能；把问题发生时的时间和进程记录下来。

## 参考资料

- [Ubuntu Server 文档](https://documentation.ubuntu.com/server/)
- [服务商官方说明](https://bandwagonhost.com/kb.php?action=displayarticle&id=30)