遇到服务器卡顿，先别急着重启，用这套命令组合能快速圈出是 CPU、内存还是 IO 出了问题，适合紧急故障排查场景。
先说结论：这 9 条命令是 Linux 运维社区长期总结的快捷检查组合，能覆盖大部分性能瓶颈，但不能替代深度分析。
- 先定位：确认是系统负载高还是单个进程异常
- 先做：优先检查 CPU 等待和内存可用量，排除硬件资源耗尽
- 再验证：根据命令输出决定是扩容、优化代码还是调整配置
环境准备：确保工具可用
部分命令属于 sysstat 包，最小化安装的系统可能缺失。执行前请确认环境，建议提前安装。
# CentOS/RHEL
sudo yum install -y sysstat
# Ubuntu/Debian
sudo apt install -y sysstat注意：多数命令需要 root 权限才能看到完整信息，建议在命令前加 sudo 或切换至 root 用户。
命令速用版
1. uptime
2. dmesg | tail
3. vmstat 1
4. mpstat -P ALL 1
5. pidstat 1
6. iostat -xz 1
7. free -m
8. sar -n DEV 1
9. top重要提示：带参数 1 的命令会持续每秒输出，按 Ctrl+C 可停止。若只需查看指定次数，可加次数参数，如 vmstat 1 5 表示采样 5 次后自动停止。
分步实操与输出解读
第一步：看系统负载和历史
运行 uptime 查看最近 1、5、15 分钟的负载平均值。如果数值超过 CPU 核心数，说明有排队现象。
10:30:05 up 10 days, 2:30, 1 user, load average: 0.50, 0.80, 1.20接着运行 dmesg | tail 检查内核日志，确认是否有 OOM（内存溢出）杀进程或硬件报错记录。
第二步：查内存和交换分区
运行 free -m。重点看 available 列，而不是 used 列。Linux 会把空闲内存用于缓存，used 高不代表内存不足。
total used free shared buff/cache available
Mem: 7982 1200 500 10 6282 6500
Swap: 2048 0 2048如果 swap 使用量持续增加，说明物理内存确实不够。
第三步：查 CPU 和进程
运行 sudo mpstat -P ALL 1 查看每个核心的使用情况，确认是否单核瓶颈。配合 sudo pidstat 1 找出具体是哪个进程占用了 CPU 或发生了频繁上下文切换。
第四步：查磁盘和网络
运行 sudo iostat -xz 1，关注 %util 和 await 列。如果 %util 接近 100% 或 await 很高，说明磁盘 IO 是瓶颈。
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
sda 0.50 1.20 4.00 12.00 0.00 0.10 0.00 2.00 0.10 0.20 0.00 8.00 10.00 0.50 0.08运行 sudo sar -n DEV 1 查看网卡流量，确认是否打满带宽。
第五步：综合监控
最后运行 top 或 htop 保持实时观察，配合前面的数据做最终确认。按 q 键可退出 top。
验证与常见坑
检查的目的是为了找到方向，验证标准是“是否找到了资源瓶颈”。
- 如果
vmstat的 si/so 列有数值，说明 swap 在频繁交换，内存不足。 - 如果
iostat的 %util 长期高于 80%，说明磁盘 IO 饱和。 - 如果
mpstat显示某核 100% 而其他空闲，说明程序多线程优化有问题。
常见避坑指南：
- 命令不存在：需提前安装 sysstat 包。
- 权限不足：遇到 Permission denied 请加 sudo。
- 误判内存：重点看 available，不要只看 free。
- 命令停不下来：持续采样命令请按 Ctrl+C 强制停止。
- 采样时间：只跑一两秒可能看不到波动，建议观察至少一个业务周期。