当 Linux 服务器出现响应变慢、吞吐下降、负载异常升高、请求超时或用户投诉“卡顿”时，不要第一时间去看代码或升级硬件。正确的起点是用最短时间判断瓶颈属于哪一类资源：CPU 计算饱和、内存压力、磁盘 I/O 等待、网络饱和、还是锁/调度/线程阻塞。
以下是 2025–2026 年生产环境中最实用、最高效的初步判断方法，通常 3–10 分钟内就能把问题范围缩小到 1–2 个方向。
按以下顺序快速执行，观察关键指标：
| 顺序 | 命令 | 核心观察点（异常阈值参考） | 指向的瓶颈类型 |
|---|---|---|---|
| 1 | uptime 或 cat /proc/loadavg | load average（1/5/15 min）> 核数×1.5–2.5 持续 | 整体有等待（IO/锁/网络/大量线程） |
| 2 | top / htop（按 1 查看多核） | %Cpu(s)：us+sy >80–90%，id<10%，wa/iowait>15–20% | CPU 计算 / 磁盘 IO 等待 |
| 3 | free -h -w 或 vmstat 1 5 | available < 总内存 10–15%，si/so 非零且持续 | 内存压力 / swap 抖动 |
| 4 | iostat -xmdz 1 5 或 iostat -x 1 | %util >80–90%（单个盘接近100%），await >10–20ms | 磁盘 I/O 饱和 |
| 5 | ss -s 或 sar -n DEV 1 5 | retransmitted / timeouts / listen drops 非零且高 | 网络拥塞 / 丢包 / 连接堆积 |
| 6 | mpstat 1 5 或 sar -q 1 5 | runq-sz（运行队列）持续 > 核数×2，procs.r 高 | CPU 饱和 或 严重锁/调度竞争 |
快速判断口诀： 负载高 → top看 wa/iowait → free看 available → iostat看 %util → ss看重传 → mpstat看 runq-sz
| 瓶颈类型 | 典型 top / htop 画面特征 | 关键量化指标（粗略阈值） | 常见罪魁祸首进程/场景 | 下一秒确认命令 |
|---|---|---|---|---|
| CPU 密集 | us+sy 持续 80–100%，id 很低，load 高，runq-sz 大 | us+sy >80%，runq-sz > 核数×2 | 循环、正则、加密、压缩、机器学习推理 | pidstat -u 1 5 或 top 按 P 排序 |
| 内存压力 | available 接近 0，swap used 上升，si/so 非零 | available <5–10%，SwapIn/Out >0 且持续 | 内存泄漏、大对象缓存、缓存挤占、进程 fork 爆炸 | vmstat 1、smem -t -k、ps -eo rss,cmd --sort=-rss |
| 磁盘 I/O | wa/iowait 10–50%，%util 高，await/svctm 大 | %util >80–90%，await >10–30ms | 日志狂写、数据库慢查询、大文件扫描、备份 | iotop（需安装）、pidstat -d 1、iostat -x |
| 网络饱和 | CPU/IO 不高，load 高，重传/丢包/连接建立慢 | retrans >1–5%、drops 非零、TIME_WAIT 堆积 | DDoS、大流量、慢客户端、MTU 不匹配、NAT 瓶颈 | ss -m -o state established、sar -n DEV、mtr |
| 等待/锁竞争 | CPU 不高，load 高，大量进程 S/D 状态，runq-sz 不大 | 大量 futex/epoll_wait/D 状态，runq-sz 正常 | 数据库锁、文件锁、Redis 单线程、大量阻塞 I/O | strace -c -p PID、perf top、bpftrace |
正确心态：“先用数字证明瓶颈类型，再找具体进程/配置”
其中 glances（一屏概览所有资源）与 btop（现代美观版 top）特别适合快速判断。
用这套方法，大部分线上“服务器变慢”的问题都能在 10 分钟内明确瓶颈类别，避免盲目调参或加机器。后续再针对性使用 Brendan Gregg 的 USE 方法（Utilization / Saturation / Errors）或 perf/bpftrace 做深度分析。
这是从“会敲 top”到“能快速定位瓶颈”的关键一步。
网站资讯
关于我们
