Linux 服务器性能排查

性能问题出现时（响应变慢、负载飙升、请求超时、吞吐下降等），最致命的不是技术深度不够，而是排查顺序混乱。正确的思路是先全局定性、再分层定位、最后针对性深挖，而不是一上来就 strace / perf / gdb。

以下是 2025–2026 年生产环境中，经过 Netflix、Brendan Gregg、Red Hat 等验证过的完整、可重复的排查框架，分为四个阶段。

第一阶段：症状收集与基线对比（1–3 分钟）

目标：明确“到底慢在哪里”，建立问题画像。

必问 5 个问题（自己回答或问业务）：

慢是从什么时候开始的？有无明显触发事件（代码发布、流量峰值、配置变更）？
是所有请求慢，还是部分接口/用户慢？
是 CPU/内存/磁盘/网络/数据库其中哪类资源最明显异常？
历史基线如何？（正常时 load/响应时间/qps 大概多少？）
有无告警？（Prometheus/Grafana/Zabbix 等是否有 Utilization/Saturation/Errors 异常）

立即执行的 6 条命令（复制粘贴顺序跑）：

uptime → load average 与核数对比
top / htop（按 1 看多核，按 M 看内存，按 P 看 CPU 排序）
free -h -w → 重点看 available 而非 used
vmstat 1 5 → 看 si/so（swap）、wa（iowait）、r（运行队列）
iostat -xmdz 1 5 → %util、await、r/s、w/s
ss -s → retransmitted、timeouts、listen drops

这一步输出一句话总结，例如： “load 45（32 核），iowait 35%，%util 多个盘 95%，available 内存 8%，初步判断磁盘 IO 饱和 + 内存压力”

第二阶段：USE 方法快速扫描（3–10 分钟）

Brendan Gregg 的 USE 方法（Utilization 利用率、Saturation 饱和度、Errors 错误）是目前最系统化的资源检查框架。

针对服务器最常见的 5 类资源逐一过一遍：

资源	Utilization（利用率）	Saturation（饱和度）	Errors（错误）	关键命令 / 阈值警戒线
CPU	us + sy > 80–90%	runq-sz > 核数 × 1.5–2，r 列持续高	softirq、steal（虚拟化）高	mpstat -P ALL 1 5、pidstat -u 1 5
内存	available < 总内存 10–15%	swap in/out 非零且持续，kswapd0 CPU 高	OOM killer 日志	free -h -w、vmstat 1、cat /proc/meminfo
磁盘	%util > 80–90%（单个盘）	await > 10–30ms，queue length 高	i/o error、timeout 日志	iostat -x 1 5、iotop、pidstat -d 1
网络	网卡 rx/tx 接近带宽上限	重传率 > 1–5%，listen queue drops	packet drops、tcp timeout	sar -n DEV 1 5、ss -s、netstat -s
进程/线程	—	大量 D/S 状态进程，futex/epoll_wait 等待	—	ps -eo state,pid,ppid,cmd \| grep ‘ D’

快速分类口诀：

CPU 饱和 → us+sy 高 + runq-sz 高
内存压力 → available 低 + swap 活动
磁盘瓶颈 → %util 高 + await 高
网络问题 → retrans 高 + drops 非零
等待/锁 → CPU 不高但 load 高 + 大量 D/S 状态

第三阶段：锁定嫌疑进程与调用链（5–20 分钟）

根据第二阶段结论，针对性深挖：

A. CPU 密集型

pidstat -u 1 5 | sort -k 8 -nr | head -15 → Top CPU 进程
top 按 P 排序 → 看哪些线程吃 CPU
perf top 或 perf record -F 99 -p PID -g — sleep 30 → 火焰图分析热点函数

B. 内存压力 / 泄漏

ps -eo pid,rss,vsz,cmd –sort=-rss | head -15 → 驻留内存 Top
smem -t -k -c “pid user command uss pss rss” → 更精确的用户空间内存
journalctl -k | grep -i “oom\|killed” → 检查 OOM killer

C. 磁盘 I/O 瓶颈

iotop -o（只显示有 IO 的进程）
pidstat -d 1 5 → 按磁盘读写排序
lsof +D /var/log 或 lsof | grep deleted → 查找被删但还在写的日志文件

D. 网络 / 连接问题

ss -m -o state established | wc -l → 连接数
ss -K dst 1.2.3.4（杀掉特定 IP 连接）
tcpdump -i eth0 port 80 -nn -c 100 → 抓包看是否有大量重传/SYN

E. 锁 / 等待 / 阻塞

strace -c -p PID 或 strace -f -p PID → 看卡在哪个系统调用
perf record -e syscalls:sys_enter_futex … → futex 等待分析
bpftrace 一行脚本追踪阻塞点

第四阶段：验证 + 根因确认 + 修复闭环

假设验证：临时 kill / stop 嫌疑进程，看指标是否恢复
日志交叉：journalctl -u 服务名 -b + dmesg -T + /var/log/应用日志
基线对比：修复后再次跑第一阶段命令，对比变化
长期监控：Prometheus + node_exporter + Grafana（USE/RED 仪表盘）
文档记录：写成 incident report（症状 → 指标 → 根因 → 修复 → 预防）

完整排查流程总结图

text

报警 / 投诉 → 症状收集（uptime/top/free/iostat/ss）
          ↓
USE 扫描（CPU/内存/磁盘/网络/进程等待）
          ↓
定位资源类型
   ├── CPU → pidstat/perf top/火焰图
   ├── 内存 → ps/smem/oom 日志
   ├── 磁盘 → iotop/pidstat -d/lsof deleted
   ├── 网络 → ss/sar -n DEV/tcpdump
   └── 等待 → strace/perf/bpftrace
          ↓
假设验证 + 日志确认
          ↓
修复 + 监控验证 + 复盘预防

生产环境口诀： “先 60 秒全局扫（Netflix 60s），再 USE 定资源，再进程定嫌疑，最后深工具确认。”

遵循这个顺序，95% 的性能问题都能在 30 分钟内找到主要瓶颈，避免盲目重启、加机器或改参数。后续可以系统学习 Brendan Gregg 的《Systems Performance 2nd》或 Netflix 的 perf 文章。

云服务器

裸金属服务器

独立服务器

主机和域名

Linux 服务器性能排查