服务器响应变慢需四步排查：一、用uptime/top/vmstat快速摸底全局负载；二、分CPU、内存、磁盘三线并查，定位资源瓶颈；三、用pidstat/ps/strace等锁定高耗资源进程及行为；四、通过ss/dig/telnet等排除网络、DNS、下游依赖及定时任务干扰。
服务器整体响应变慢，不能只盯一个指标或一个命令。关键在于建立清晰的排查路径：先看全局水位，再分层下钻，最后交叉验证。下面这四步是生产环境反复验证过的高效组合，每一步都对应明确目标和可执行命令。
一、快速摸底：用 uptime + top + vmstat 看清“整体在喘气还是快断气”
登录后立刻执行这三条命令，不需安装额外工具：
- uptime：看 load average 三个值，结合 CPU 核数判断是否排队。例如 8 核机器，1 分钟负载 > 8 就说明有进程在等资源；若 1 分钟远高于 15 分钟，说明刚爆发问题，要立刻抓活数据。
- top -c：按 1 键展开各 CPU 核使用率，防止单核打满拖垮服务；按 P 排 CPU、M 排内存；重点关注 wa（IO 等待）是否 >20%，sy 是否异常高（内核态过载），以及 available 内存是否低于总内存 10%。
- vmstat 1 5：重点看 r（运行队列长度）、b（阻塞进程数）、wa 和 cs（上下文切换）。r > CPU 核数 或 b > 0，说明系统已不堪重负；cs 突增 5 倍以上，大概率存在锁争用或短周期调度干扰。
二、分资源聚焦：CPU、内存、磁盘三线并查
根据上一步线索，同步打开三个终端（或用 tmux 分屏），分别盯住一类资源：
- CPU 方向：运行 mpstat -P ALL 1 3，确认是用户态（us）高（代码问题）、内核态（sy）高（驱动/中断）、还是 iowait（wa）高（实际是磁盘慢，不是 CPU 真忙）。
- 内存方向：运行 free -h 和 cat /proc/meminfo | grep -E "MemAvailable|SwapTotal|SwapFree|Buffers|Cached"。MemAvailable 低 + SwapFree 快见底 + si/so 持续非零，就是内存不足触发换页，性能必然断崖下跌。
- 磁盘方向：运行 iostat -x 1 5，紧盯 %util（接近 100% 表示设备饱和）、await（平均 IO 耗时，>10ms 需警惕）、r/s 和 w/s（读写频次是否突增）。若 %util 高但 r/s/w/s 很低，可能是单个大 IO 卡住，不是吞吐瓶颈而是延迟瓶颈。
三、锁定进程：从“谁在占资源”到“它在干什么”
找到资源大户后，别急着 kill，先看清行为逻辑：
- 用 pidstat -u 1 5 查哪个进程 CPU 高，同时区分 us/sy/wa 占比；用 pidstat -r 1 5 查内存增长趋势；用 pidstat -d 1 5 查 IO 读写量。
- 对可疑 PID，用 ps -T -p $PID 查线程级状态，再用 top -H -p $PID 看哪个线程吃 CPU；用 lsof -p $PID | wc -l 查文件句柄数是否逼近 ulimit 限制。
- 如需深挖行为，用 strace -p $PID -e trace=io,file,net -T 捕获耗时长的系统调用（比如 read() 卡 3 秒，说明后端存储或网络依赖超时）；用 pstack $PID 或 gdb -p $PID -ex "thread apply all bt" -ex quit 看线程堆栈，识别卡点（如 Java 停在 Object.wait，Go 卡在 futex）。
四、排除外部干扰：别让下游背锅
很多“服务器变慢”其实根子不在本机：
- 用 ss -s 或 netstat -s | grep -i "retransmit\|overflow\|drop" 查 TCP 重传、连接队列溢出、包丢弃——这些常指向网络链路或对端服务问题。
- 用 dig +short example.com @8.8.8.8 或 time nslookup example.com 测试 DNS 解析是否变慢；用 telnet db-host 3306 或 curl -v http://upstream-api/health 直连依赖服务，确认是否响应延迟或超时。
- 检查定时任务：ls /etc/cron.*、systemctl list-timers --all，很多“整点卡顿”都是日志轮转、备份脚本或监控采集引起的。
