Linux 性能分析

目标

用低侵入方式定位 Linux 性能瓶颈。
先看系统整体压力，再下钻到 CPU、内存、I/O、网络和具体进程，最后明确瓶颈子系统、内核态/应用态归因，以及主要触发进程。

何时使用

• Linux 主机运行缓慢、卡顿、过载、延迟高
• 平均负载高、CPU 使用率异常、CPU 主频异常降低、I/O 等待高
• 内存紧张、频繁交换内存、OOM、主缺页异常
• 磁盘读写慢、文件系统满、inode 耗尽、进程阻塞在 I/O
• 丢包、重传、连接堆积、超时、网络吞吐或延迟异常
• 用户只提供了命令输出，需要基于现有证据判断瓶颈

何时不要使用

• 问题不是 Linux 主机或容器运行时性能问题
• 用户只是在问某个命令的语法，不需要做诊断
• 已经明确是业务代码逻辑缺陷，应优先用系统化排查

安全级别

默认使用最低侵入方式，尤其是生产环境。

• L1：默认，只读、低开销观察，例如 uptime、top、vmstat、iostat、ss
• L2：短时间采样，有明确时长和目标，例如 pidstat 1 3
• L3：附加进程、追踪、抓包、eBPF、主动压测，例如 perf、strace、tcpdump、iperf3

执行 L3 前必须先确认：

1. 主机是否生产环境
2. 采样时间窗口
3. 预期风险或开销
4. 明确的持续时间、数据包数量或样本上限

基本流程

1. 明确症状、时间窗口、影响范围
2. 复用用户已有输出；不足时先补轻量基线
3. 横向检查 CPU、内存、I/O、网络，避免只盯第一个异常指标
4. 对可疑子系统从系统级下钻到进程、线程、设备、套接字
5. 判断主要瓶颈在内核态还是应用态
6. 给出证据、结论、下一条最能减少不确定性的命令

基线

优先从这些只读命令开始：

uname -a
uptime
top -b -n 1
vmstat 1 5
pidstat 1 3

如果某个方向已经明显异常，再读取对应参考：

• CPU：references/cpu.md
• 内存：references/memory.md
• I/O：references/io.md
• 网络：references/network.md
• 报告模板：references/report-template.md

判断规则

• 高 %wa 通常先查 I/O，不要简单归为 CPU 问题
• 负载高但 CPU 不高时，重点看阻塞任务、I/O、锁等待
• CPU 忙但吞吐低或延迟高时，检查频率调节器、性能模式、当前主频、最大/最小频率限制和热降频
• 高 %sy、%si、%hi、重传、积压队列压力通常指向内核或网络路径
• 交换内存、主缺页、内存回收停顿、OOM 指向内存压力
• 网络问题可能由 CPU 饱和、套接字积压队列、应用读写慢共同触发

内核态与应用态

• 应用态：用户进程、业务线程、GC、SQL、序列化、压缩、请求处理等成本占主导
• 内核态：调度、软中断、中断、回收、文件系统、块层、TCP/IP、驱动、系统调用路径占主导
• 混合场景：如果应用触发大量内核工作，要同时说明“瓶颈层在内核态”和“触发进程是谁”

输出要求

最终结论必须明确回答：

1. 主要瓶颈是 CPU、内存、I/O 还是网络
2. 瓶颈主要在内核态还是应用态
3. 如果涉及应用态，哪个进程是主要触发者

证据不足时，不要强行定论。说明已经确认什么、仍然怀疑什么，并给出下一条最值得执行的命令。

关键约束

• 先看证据，再下结论
• 先系统级，再进程级
• 不主动运行有负载或高侵入命令
• 不把缓存占用直接当成内存泄漏
• 不把单个异常指标直接当成根因