linux-performance-analysis git:20260905.751659eA

Immutable. This exact content never changes and is served at /api/v1/blob/0f8200d1006faa07.

---
name: linux-performance-analysis
description: 诊断 Linux 主机或容器的缓慢、高负载、资源压力及网络性能异常，定位瓶颈与触发进程；不用于普通命令语法查询。
---

# 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. 给出证据、结论、下一条最能减少不确定性的命令

## 基线

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

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

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

- CPU：[references/cpu.md](references/cpu.md)
- 内存：[references/memory.md](references/memory.md)
- I/O：[references/io.md](references/io.md)
- 网络：[references/network.md](references/network.md)
- 报告模板：[references/report-template.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. 如果涉及应用态，哪个进程是主要触发者

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

## 关键约束

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