服务器卡顿是资源供需失衡的明确信号，需按cpu（看uptime和top）、内存（用free和vmstat）、磁盘io（用iostat和iotop）、网络与日志（用ss和dmesg）四步快速定位瓶颈。
服务器卡顿不是随机发生的，而是资源供需失衡的明确信号。关键不是“哪个命令最炫”，而是用最少步骤快速锁定是CPU、内存、磁盘IO还是网络出了问题。
CPU瓶颈：看负载和状态分布
先执行 uptime，看三个平均负载值（1/5/15分钟）。如果最后一个值持续高于 CPU 核心数（可用 nproc 查），说明有进程在排队等 CPU。再运行 top，重点关注顶部两行：
- %Cpu(s) 行里 us（用户态）高 → 应用逻辑或计算密集型任务占满；
- sy（内核态）高 → 可能是频繁系统调用、上下文切换或中断处理过多；
- wa（iowait）高 → 实际不是 CPU 问题，而是进程在等磁盘响应，要转去看 IO；
- st（steal）高 → 云主机被宿主抢占，需联系厂商或扩容。
内存瓶颈：警惕 Swap 和可用内存
运行 free -h，重点看三列：
- available 值远低于总内存 → 真实可用内存不足；
- swap used 明显增长，且 si/so（swap in/out）在 vmstat 1 5 中持续非零 → 内存严重不足，进程频繁换页，响应必然变慢；
- 即使 free 值不低，但 buff/cache 占比异常高，且应用响应迟缓 → 可能是内核缓存挤占了可分配内存，需结合 slabtop 看内核对象占用。
磁盘IO瓶颈：从总量到进程逐层下钻
先用 iostat -xz 1 看整体设备指标：
- %util > 70% 且 await > 10ms（机械盘）或 > 1ms（SSD）→ 设备已饱和；
- r/s + w/s 远超设备理论 IOPS → 吞吐过载；
- avgqu-sz 持续大于 1 → 队列堆积，请求在排队。
确认是 IO 问题后，立刻执行 sudo iotop -o，找出实时写入或读取最猛的进程。再用 ps -p PID -o pid,ppid,comm,args 定位具体服务和参数。
网络与日志：别漏掉连接和错误线索
运行 ss -s 或 netstat -s | grep -i "drop\|retransmit\|failed"，看是否有大量连接丢包、重传或失败。同时快速扫一眼 dmesg -T | tail -20，检查最近是否有硬件报错、OOM killer 杀进程、或磁盘 I/O timeout 类警告。这些信息往往比性能数字更直接指向根因。
