Linux 排查：先观察资源，再验证瓶颈

服务变慢时，最容易做的事是打开 top，然后被某个显眼的数字吸引。真正的排查应先确定症状，再把应用表现和系统资源放在同一个时间窗口比较。

本文合并重写自《Linux 常用操作指南》和《Linux 服务器检查指南》，保留观察方法，去掉旧 JVM 配置和固定阈值。命令以 Linux 常见工具为例；有些需要另行安装或相应权限。

先定义慢在哪里

记录开始时间、受影响请求、延迟分布、错误比例和近期变更。平均延迟相同，不代表尾部请求相同；没有错误，也不代表用户没有等待。

Google SRE 用延迟、流量、错误和饱和度概括服务监控的主要方向。这里借用它作为观察入口，而不是把主机 CPU 当成服务质量的全部。监控分布式系统

uptime
free -h
df -h
df -i
vmstat 1 5

uptime 的 load average 不是 CPU 使用率。在 Linux 中，它包括可运行任务和不可中断睡眠任务的负载情况，需要结合 CPU 数量与 I/O 等待分析，不能套用“超过 0.7 就危险”的统一阈值。见 proc_loadavg(5)。

free 中的空闲内存少，也不自动意味着内存不足。关注 available、交换活动和应用表现；swap 已使用不等于正在频繁换入换出。vmstat 的首行通常反映自启动以来的统计，后续行才对应采样间隔。内存字段见 free(1)。

df -h 检查容量，df -i 检查 inode。大量小文件可能在容量耗尽前用完 inode。

ps -eo pid,ppid,comm,%cpu,%mem --sort=-%cpu
ss -lnt

前者是进程快照，后者显示监听中的 TCP 套接字。它们用于提出下一步假设，不能单独证明根因。进程 CPU 高，要继续判断是否有有效工作；CPU 低但请求慢，可能在等待数据库、网络或锁。

需要进一步观察磁盘时可以使用 iostat，检查日志时可以使用系统服务日志或应用日志。不要一次改多个参数，否则即使恢复，也很难知道是哪项变化起了作用。

GNU 工具中可以用下面的命令查看当前目录下的占用：

du -h --max-depth=1 . | sort -h
find ./logs -type f -mtime +7 -print

人类可读的 1G、900M 应使用支持单位的 sort -h，不能简单按数字排序。find 的时间条件按整段时间计算，不等于自然日；先打印匹配结果，核对路径和范围，再另行决定是否删除。

打包与压缩也不是一回事：tar -cf archive.tar notes/ 只归档，tar -czf archive.tar.gz notes/ 额外使用 gzip。提取前可用 tar -tf archive.tar 查看成员，避免不了解内容就直接覆盖现有目录。

假设磁盘写入是瓶颈，就观察相同时段的写入延迟、队列和应用等待；假设某次发布造成回退，就比较版本、请求和数据规模。每项观察都应能支持或削弱某个判断。

恢复服务与找到根因可以分开推进，但恢复动作也要记录。重启解决了眼前问题，并不说明问题已经消失；它可能只是清空了积累的状态。

排查记录最后应留下现象、证据、采取的动作和验证结果。下次遇到类似问题时，这些内容比一张脱离上下文的命令清单更有用。

命令字段与历史输出示例可配合服务器检查笔记阅读；Linux 实战整理了更多文件与文本操作。