Linux 服务器负载高怎么办：从 CPU、内存到磁盘 I/O 的排查顺序

Linux 服务器突然变慢、网站出现 502、SSH 卡顿或负载飙升时，最重要的不是立刻重启，而是先确认问题来自 CPU、内存、磁盘 I/O、网络，还是某个服务进程。下面是一套适合 Web 服务器和常见 VPS 的排查顺序，既能缩短恢复时间，也能为后续优化留下依据。

第一步：先确认“负载高”意味着什么

使用 uptime 或 top 查看 load average。负载不等于 CPU 使用率，它也可能包含等待磁盘 I/O 的任务。判断时要把负载与 CPU 核心数、CPU 使用率和 iowait 一起看。

uptime
top
free -h
df -h

CPU 很闲但负载很高时，优先怀疑磁盘等待；内存耗尽并且 swap 持续增长时，优先找异常进程或并发配置；磁盘空间接近满时，日志、缓存或临时文件都可能让服务异常。

第二步：找出占用资源的进程

先按 CPU 和内存排序，不要直接结束不认识的进程。记录 PID、所属用户、启动时间和命令行，再判断它是否属于 Nginx、PHP-FPM、MySQL、备份任务、爬虫任务或应用程序。

ps aux --sort=-%cpu | head -n 15
ps aux --sort=-%mem | head -n 15
top -o %CPU

Web 站点常见的异常来源包括 PHP-FPM 子进程过多、慢查询堆积、备份压缩占满 CPU、日志轮转失败、持续爬虫请求，或计划任务在同一时段重叠执行。

第三步：检查内存与 OOM 风险

free -h 中的 available 比单看 free 更有参考价值。Linux 会将空闲内存用于缓存，这是正常现象；真正需要关注的是可用内存很低、swap 持续被使用，或内核已经触发 OOM（内存不足）回收。

free -h
vmstat 1 5
dmesg -T | tail -n 80

如果出现 OOM 记录，先减少异常并发或修复内存泄漏，再评估 PHP-FPM、数据库缓存和容器的内存上限。单纯增加 swap 只能缓冲突发，不应替代容量规划。

第四步：排查磁盘空间和 I/O 等待

磁盘满会导致数据库无法写入、缓存失效、会话丢失甚至网站 502。除了 df -h，还要查 inode 是否耗尽，以及哪些目录正在增长。

df -h
df -ih
du -xh /var | sort -h | tail -n 20
journalctl --disk-usage

不要直接删除正在写入的日志文件。更稳妥的做法是先定位来源，确认日志轮转策略、备份保留周期和缓存目录。对于已删除但仍被进程占用的文件，可用 lsof +L1 识别，再按服务维护流程重载对应进程。

第五步：检查 Web 与数据库服务

网站慢不一定是服务器整体慢。应分别检查反向代理、PHP-FPM 和数据库的错误日志与服务状态：

systemctl status nginx
systemctl status php-fpm
systemctl status mysql
ss -lntp

当 PHP-FPM 队列堆积时，查看慢日志和最大子进程配置；当 MySQL CPU 高或连接数异常时，先找慢查询和锁等待。修改服务参数前记录原值，并一次只改一项，方便确认优化是否有效。

第六步：确认流量、爬虫与异常请求

突发流量、恶意扫描和失控爬虫会把正常站点拖慢。结合访问日志查看请求量、状态码、耗时路径和来源 IP，重点关注大量 404、登录接口、XML-RPC、搜索页和动态参数。

tail -n 200 /var/log/nginx/access.log
tail -n 200 /var/log/nginx/error.log

对确定的恶意流量可在 CDN、防火墙或 Web 服务器层做限速与拦截；不要因为一次峰值误封正常搜索引擎或真实用户。

恢复后的优化清单

• 为备份、压缩、扫描等重任务安排低峰期，并避免并发重叠。
• 启用 CPU、内存、磁盘、I/O、响应时间和错误率的基础监控。
• 为日志、缓存和备份设置保留周期，定期检查磁盘增长。
• 优化缓存和数据库慢查询，而不是长期靠重启服务缓解问题。
• 保留一次故障记录：发生时间、症状、进程、日志线索、处理动作和验证结果。

结语

排错的关键是按顺序缩小范围：先看全局资源，再定位进程，再深入服务与日志。养成记录和监控习惯后，大多数“服务器卡住”的问题都能更快定位，也更容易转化为稳定的长期优化。

站内延伸阅读：Linux 教程、WordPress 运维、网络安全文章。