在 Linux 环境下排查系统故障，最推荐的做法是先通过顶层指标（如负载、内存、磁盘）快速定位资源瓶颈，再结合日志确认具体进程或服务，优先恢复业务而非立即根因分析。

命令速用版

uptime          # 查看系统负载和运行时间
top             # 实时查看进程资源占用
dmesg -T        # 查看内核环形缓冲区信息，带时间戳
journalctl -xe  # 查看 systemd 系统日志详情
df -h           # 检查磁盘空间使用率
free -h         # 检查内存使用情况

关键指标解读

执行命令后需关注以下核心阈值，避免误判：

• Load Average：若数值超过 CPU 核心数（使用 nproc 查看），说明存在任务排队。
• iostat %util：若持续超过 80%，表明磁盘 IO 达到瓶颈。
• 内存 available：free -h 中 available 列接近 0 才视为内存不足，buff/cache 占用高属正常现象。

分步处理

第一步：评估系统整体负载
执行 uptime 或 w 命令。如果 load average 远高于 CPU 核心数，说明存在计算或 IO 排队。此时不要急于重启，先记录当前状态。

第二步：定位资源瓶颈
使用 top 命令，按 P 键按 CPU 排序，按 M 键按内存排序。观察是否有单一进程占用过高。如果是磁盘问题，使用 iostat -x 1 查看 IO 等待情况，关注 await 和 %util 列。

第三步：检查系统日志
执行 dmesg -T | tail -n 50 查看是否有硬件错误或 OOM 杀进程记录。对于使用 systemd 的系统，journalctl -u 服务名 `--since` "10 min ago" 能快速定位特定服务报错。

第四步：临时止血措施
若是磁盘满，可使用 find /var/log -name "*.log" -mtime +7 -delete 清理旧日志（操作前建议先备份或确认文件无用）；若是内存泄漏，尝试重启该服务而非整机，命令为 systemctl restart 服务名，注意重启前确认服务是否支持状态保存；若是异常进程，确认非系统关键进程后可暂时停止。

典型故障案例实战分析

场景：业务响应突然变慢，SSH 连接延迟高。

排查：uptime 显示负载过高，但 CPU 使用率不高。检查 iostat -x 1 发现 %util 接近 100%，await 值极高。

解决：定位到某日志进程频繁写入，临时限制其 IO 优先级或清理磁盘空间后恢复。

怎么验证是否生效

执行 uptime 确认负载数值是否下降至正常范围（通常接近 CPU 核心数或更低）。检查关键业务端口是否正常监听（使用 ss -tlnp）。查看日志文件最后几行，确认不再持续出现错误堆栈或报警信息。

常见坑

• 盲目杀进程：直接 kill 掉占用高的进程可能导致数据不一致或业务中断，需先确认进程用途。
• 忽略磁盘 inode：磁盘空间未满但 inode 耗尽也会导致无法写入文件，需用 df -i 检查。
• 日志 flooding：故障时日志可能瞬间写满磁盘，建议配置日志轮转或临时关闭 debug 级别日志。
• 缓存误导：free 命令显示的可用内存包含缓存，实际可用内存需看 available 列，不要误判为内存泄漏。