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

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

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

uptime
nproc
free -h
vmstat 1 10

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

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

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

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

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

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

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、磁盘清理、后台任务管理或WordPress 性能优化。