Linux 性能监控的核心不在于记住所有命令，而在于快速定位瓶颈所在。通常建议从系统负载入手，依次排查 CPU、内存、磁盘 I/O 和网络连接。
先说结论：性能问题排查应遵循“先整体后局部”的原则，优先使用系统自带工具确认资源瓶颈，再针对性优化。
- 先定位：使用 top 或 uptime 确认系统负载是否异常（负载超过 CPU 核心数需警惕）。
- 先做：根据瓶颈类型选择 vmstat、iostat 或 ss 深入分析。
- 再验证：优化后对比关键指标变化（如 iowait 从 50% 降至 5%），确认问题是否缓解。
常用命令与兼容性说明
以下命令可直接在终端执行，用于快速获取系统状态。注意部分命令在不同发行版中可能存在差异：
uptime # 查看系统负载和运行时间top -p <PID> # 实时查看指定进程资源占用（PID 可通过 pgrep <进程名> 获取） # 注意：旧版 pgrep 可能不支持 -d 参数，建议分步执行vmstat 1 # 查看虚拟内存和 CPU 状态（每秒刷新）iostat -x 1 # 查看磁盘 I/O 统计ss -s # 查看网络连接状态统计（替代已废弃的 netstat）
关键指标异常阈值参考
在排查前，了解以下指标的常规异常阈值有助于快速判断：
- Load Average：持续超过 CPU 逻辑核心数的 1.5 倍视为高负载。
- CPU Usage：us + sy 持续超过 80% 需关注。
- Memory：available 内存低于总内存 10% 且 swap 频繁使用。
- I/O Wait：%iowait 持续超过 30% 通常表示磁盘瓶颈。
- Network：大量 CLOSE_WAIT 或 TIME_WAIT 连接堆积。
分步排查流程
1. 确认系统负载
首先执行 uptime 查看负载平均值。如果负载远高于 CPU 核心数，说明系统过载。
2. 排查 CPU 问题
使用 top 命令，观察 us（用户空间）和 sy（内核空间）占比。如果 us 高，检查占用 CPU 最高的进程；如果 sy 高，可能涉及频繁的系统调用或驱动问题。
3. 排查内存问题
使用 free -h 查看可用内存。注意 Linux 会利用空闲内存做缓存，重点看 available 列而非 free 列。如果 swap 使用量持续增加，说明物理内存不足。
4. 排查磁盘 I/O
使用 iostat 查看%iowait 值。如果该值较高，说明 CPU 在等待磁盘读写，需检查是否有大量日志写入或数据库查询。
5. 排查网络问题
使用 ss -s 查看连接状态。如果发现大量 TIME_WAIT 或 CLOSE_WAIT，可能需要调整内核参数或检查应用连接释放逻辑。
实战案例：模拟高负载排查
假设某服务响应变慢，排查步骤如下：
- 执行
uptime发现 load average 为 8.0，而机器为 4 核，确认过载。 - 执行
top发现某 Java 进程 CPU 占用 90%。 - 结合日志发现该进程正在进行大量全表扫描。
- 优化 SQL 后，再次观察
top，该进程 CPU 降至 10%，系统负载恢复正常。
怎么验证是否生效
优化措施实施后，需通过具体指标对比确认效果，而非仅凭感觉：
- CPU 优化：top 中目标进程 CPU 占比应明显下降（例如从 90% 降至 20%）。
- I/O 优化：iostat 中的%iowait 应降低（例如从 50% 降至 5%）。
- 业务验证：同时观察业务侧的响应时间是否恢复正常，错误率是否下降。
常见误区与坑
- 内存误解：不要看到 free 内存少就恐慌，Linux 机制会尽量利用内存做缓存，只要 available 充足通常没问题。
- top 刷新率：top 默认刷新频率可能掩盖瞬间峰值，必要时使用批处理模式记录日志分析。
- 连接状态：大量 CLOSE_WAIT 通常不是内核问题，而是应用程序没有正确关闭连接。
- 命令兼容性：新系统默认可能未安装 netstat，请优先使用 ss；pgrep 参数在不同版本间可能有差异。
参考文档
- procps-ng 官方文档 (top, vmstat, pgrep)
- Linux man-pages 项目 (iostat, ss, uptime)
- sysstat 工具包文档 (iostat)
原文链接：https://www.zjcp.cc/ask/10908.html