来源：运维技术圈 | 发布日期：2026-05-25

Linux 系统性能排查全景指南

排查框架： Brendan Gregg USE 方法论（Utilization 使用率、Saturation 饱和度、Errors 错误）逐层递进，从宏观概览到微观取证，再到 eBPF 深度追踪。

一、宏观概览：四步摸清系统状态

不要上来就盯着一个指标。按顺序跑这四个命令，建立全局认知。

1. uptime — 负载趋势

uptime
# 16:20:15 up 45 days, 1 users, load average: 45.15, 20.05, 10.12

• 1min > 15min → 突发流量
• 15min 持续高位 → 系统长期高压
• ⚠️ Load Average ≠ CPU 使用率。磁盘 I/O 等待（D 状态进程）也会计入。Load 高但 CPU 空闲时，去查磁盘。

2. dmesg — 内核"遗言"

dmesg | tail

• Out of memory → 内存爆了
• TCP: time wait bucket table overflow → 连接数过多

3. vmstat — 系统健康度

vmstat 1 3

关键列（CPU 瓶颈场景）：

r  b  us sy id wa st
8  0  85 15  0  0  0

→ r（运行队列）=8 > CPU 核数，us=85%，id=0 → CPU 瓶颈

关键列（I/O 瓶颈场景）：

r  b  us sy id  wa st
0  3   5 10 15  70  0

→ b（阻塞队列）=3，wa=70%，bi 极高 → 磁盘 I/O 瓶颈

排查决策树

vmstat 发现瓶颈
  │
  ├─ r 高 + us 高 → CPU 瓶颈 → top → perf → 查代码/GC
  ├─ wa 高 → I/O 瓶颈 → iostat → iotop → 查存储
  ├─ si/so > 0 → 内存不足 → free -h → 查泄漏
  └─ 一切正常但业务慢 → 网络/容器限流/eBPF

二、四大子系统排查

2.1 CPU 飙高

# ① 找进程
top -o %CPU   # 或 pidstat -u 1
# ② 找线程（对应 jstack 等日志）
top -H -p <PID>
# ③ 看调用栈
perf top -p <PID>

典型案例： perf top 看到 GCTaskThread::run() 占 45% → Java Full GC 打满 CPU → 排查方向转向 JVM 堆内存。

2.2 内存泄漏与 OOM

# 看 available 列，不是 free 列
free -h
# 找大户：看 RES（常驻内存），不是 VIRT
top -o %MEM
# OOM 死亡回放
grep "Killed process" /var/log/messages

2.3 磁盘 I/O

iostat -xz 1

关键指标：

• %util = 100% → 磁盘被榨干
• await > 100ms → I/O 队列严重堆积（SSD 正常应在 1-5ms）
• iotop -o → 找到写磁盘的进程

2.4 网络

ss -s                 # 连接状态概览
# TIME_WAIT 过多 → 短连接耗尽端口
# CLOSE_WAIT 大量 → 代码未关闭 Socket
sar -n DEV 1          # 网卡带宽是否跑满
tcpdump -w dump.pcap  # 抓包分析三次握手/重传

三、K8s 环境特供：CPU 限流排查

K8s 容器中，宿主机 top 显示空闲，但容器业务延迟高——很可能是 Cgroups CPU 限流。

cat /sys/fs/cgroup/cpu/cpu.stat
# nr_periods 54321
# nr_throttled 12500        ← 被限流的周期数
# throttled_time 450000000000

12500 / 54321 ≈ 23% 的时间被挂起，限流严重。

对策： 调大 resources.limits.cpu，或检查 Java GC 线程数 / Go GOMAXPROCS 是否误识别了宿主机物理核数。

四、eBPF 显微镜：偶发玄学卡顿的终结者

常规工具抓不到的短暂进程和偶发延时，eBPF（bcc-tools）在不改代码、不重启服务的情况下直接洞察内核。

execsnoop — 抓毫秒级进程

execsnoop -T
# TIME(s)     PCOMM     PID  PPID  ARGS
# 03:25:01    cron      4521 1024  /usr/sbin/cron -f
# 03:25:01    sh        4522 4521  /bin/sh -c /app/monitor.sh
# 03:25:02    curl      4523 4522  /usr/bin/curl -s http://internal.api/health

揪出 cron → monitor.sh → curl 链路——几毫秒就跑完，top 根本抓不到。

opensnoop — 查文件打开失败

opensnoop -x
# PID   COMM   FD  ERR PATH
# 20485 nginx  -1   2  /etc/nginx/conf.d/proxy.conf

ERR=2 = ENOENT（文件不存在）。配置改了不生效？应用缺文件报错？秒杀。

biolatency — I/O 延迟分布直方图

biolatency -m
#  usecs          : count    distribution
#  16 -> 31      : 128     |********** |
#  32 -> 63      : 512     |****************************************|
#  4194304 -> 8388607 : 3  |*          |

绝大多数 I/O 在 32-63 微秒，但有 3 次耗时 4-8 秒——这就是偶发超时的根因。iostat 的均值无法暴露这类长尾问题。

核心经验

性能排查不是死记命令。USE 模型层层递进：从系统负载 → Cgroups 限制 → 常规指标 → eBPF 追踪。用数据说话，在混沌中找到那根线头。

关联页面