澳八机器人 性能问题不出四大资源

好，这篇博客园 codigger 的文章（2026-09-20 14:42）覆盖了从基础到进阶的完整链路。[citation:20.6] 

我把它的核心框架提取出来，结合我自身的知识做一次结构化梳理，同时补上文章略过的"具体病症对应什

么指标"的对应关系。

---

一、排查总纲：先定方向，再钉根因

文章开头的思路非常实用——性能问题不出四大资源：[citation:20.49]

| 资源 | 典型表现 | 混淆陷阱 |

|------|---------|---------|

| CPU | 计算能力不够 | 负载高≠CPU满（可能卡在 IO wait） |

| 内存 | 空间不够、频繁换页 | free 很小≠内存不足（cache 占着） |

| 磁盘 I/O | 读写阻塞 | %iowait 可能伪装成"CPU 忙" |

| 网络 | 带宽满、连接数爆 | 连接池耗尽也能表现成"请求超时" |

文章强调了一个关键认知：top 里的 %CPU 不高，延迟可能耗在磁盘 IO 等待、内存换页，或卡在某个网

络 syscall 上。方向判错，后面全是白调。[citation:20.49]

---

二、基础四件套

文章列出的四件套和各指标的含义：[citation:20.49]

2.1 CPU / 负载：top + mpstat

top -b -n 1 | head -20

mpstat -P ALL 1 3 # 看每核分布，重点盯 %iowait

load average 的实用判法：

单核：load < 1 正常，= 1 满载，> 1 过载

多核：load / 核数 < 0.7 健康

💡 同时看 %us（用户态）、%sy（内核态）、%wa（IO 等待）、%id（空闲）。%wa 高但 %us 低 → 大概率是磁盘瓶颈，不是 CPU。

2.2 内存：free + vmstat

free -h

vmstat 1 5

文章纠正了一个常见误区：free 很小没关系，Linux 会用空闲内存做 cache。要看的是 available——它才是真正可用的内存。[citation:20.49]

available < 总内存 10% → 危险

Swap used > 0 → 内存已经不够了

vmstat 的 si/so > 0 → 正在换页，性能必然下降

2.3 磁盘：iostat + iotop

iostat -x 1 5

iotop -o

| 指标 | 健康阈值 | 含义 |

|------|:-------:|------|

| %util | < 70% | 磁盘繁忙度（注意：SSD 下 %util 可能不准确） |

| await | < 10ms | IO 响应时间 |

| rawait / wawait | — | 读写分别的等待时间，读写混合时分开看才准 |

2.4 网络：ss

ss -s # 连接统计概览

ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

两个关键异常：

| 状态 | 原因 | 快速修复 |

|------|------|---------|

| TIME-WAIT 过多 | 短连接大量建立关闭 | sysctl -w net.ipv4.tcptwreuse=1 |

| CLOSE-WAIT 过多 | 代码没正确关闭连接（socket/http 没 close） | 修代码，不是改内核参数 |

---

三、进阶三剑客：perf / strace / 火焰图

文章的核心判断：[citation:20.49]

基础四件套能"定方向"，但要"钉死根因"，得靠进阶工具。

| 工具 | 擅长看什么 | 何时用 |

|------|-----------|-------|

| perf | CPU 热点、内核态开销（on-CPU） | 哪个函数最占 CPU |

| strace | 系统调用级追踪 | 进程卡在哪个 syscall |

| 火焰图 | 把 perf 采样可视化 | 时间花在哪条调用栈 |

3.1 CPU 瓶颈：perf 抓热点

系统范围采样 30s

perf record -F 99 -ag -- sleep 30

perf report # 交互式看热点

perf top -p $PID # 实时看某个进程的热点函数

生成火焰图

perf script | stackcollapse-perf.pl | flamegraph.pl > cpu.svg

-F 99 的惯例：避开整百赫兹的采样共振（比如 100Hz 可能和 100Hz 中断锁相，采到的是偏态），99 是一个常用的"质数频率"。

3.2 内存瓶颈的延伸：perf stat 看缓存行为

perf stat -e cache-misses,cache-references,page-faults,major-faults \

 -p $PID -- sleep 10

| 事件 | 偏高意味着什么 |

|------|--------------|

| major-faults | 需要从磁盘换入的缺页——内存压力已逼出 IO |

| cache-misses | 热点数据没留在 CPU 缓存，可能有缓存行竞争或数据局部性差 |

3.3 IO 瓶颈：strace + 系统级印证

逐条看耗时（-T 显示每个 syscall 耗时）

strace -Ttt -e trace=file,network -f -p $PID

汇总统计（生产环境首选，开销小）

strace -c -f -p $PID -- sleep 5

系统级印证

iostat -x 1 && pidstat -d 1

-T 标出的高耗时 read / write / connect 就是阻塞点。某 connect 每次几百毫秒 → 问题大概率在下游/网络。

---

四、端到端实战：接口变慢 30 分钟内定位

文章的实战案例很典型：[citation:20.49]

1) 定方向

top -b -n 1 | head -20 && mpstat 1 3

2) CPU 热点 + 火焰图

perf record -F 99 -ag -p $PID -- sleep 20

perf script | stackcollapse-perf.pl | flamegraph.pl > cpu.svg

3) syscall 层

strace -Ttt -e trace=file,network -f -p $PID -- sleep 5

4) 内存 / 缓存

perf stat -e cache-misses,page-faults -p $PID -- sleep 10

free -h && vmstat 1 5

典型结论矩阵：

| 火焰图形态 | strace 表现 | 根因方向 |

|-----------|------------|---------|

| 某函数栈极宽 | 无明显高耗时 syscall | 改代码优化（序列化、算法效率低） |

| 火焰图"很干净" | connect 高耗时 | 网络/下游问题（连接池、DNS、超时） |

| 火焰图干净 | vmstat si/so > 0 | 加内存或查泄漏 |

| 内核栈宽 | 锁相关调用多 | 锁竞争/上下文切换频繁 |

---

五、文章里提到但容易忽略的坑

5.1 strace 有 ptrace 开销

文章明确提醒：strace 通过 ptrace 显著拖慢目标进程——生产慎用，避免长时间 attach。统计优先用 -c，拿完数据立刻退出。[citation:20.49]

一个不太为人知的替代方案：如果你只是想看进程卡在哪，而不用看逐次调用参数，可以用 /proc/<pid>/syscall 取当前卡住的 syscall——零开销。

cat /proc/<PID>/syscall # 当前正在执行的 syscall 编号+参数

5.2 火焰图只看了"一半"

文章也提到了：火焰图只看 on-CPU 时间——进程若卡在 IO/锁（off-CPU），火焰图会"看起来很干净"。

比如一个线程大部分时间在等磁盘 IO 或等锁，火焰图上只会在很窄的栈上显示极少采样点——这时候需要 off-CPU 火焰图（perf sched / eBPF），否则会漏判。[citation:20.49]

5.3 perfeventparanoid 权限

cat /proc/sys/kernel/perfeventparanoid

默认值多为 2~4，内核态/整机数据需要 CAPPERFMON 或 CAPSYS_ADMIN。容器内还需放开 securityContext。

---

六、一页速查表

问题来了 → 先定方向

 ├── top # CPU + Load + 内存概览

 ├── free -h # 看 available

 ├── iostat -x 1 # 看 %util + await

 └── ss -s # 看连接状态

方向定了 → 钉根因

 ├── CPU 高 → perf record -F 99 -ag + 火焰图

 ├── 卡在 IO → strace -c + iostat + pidstat

 ├── 内存不足 → vmstat 1 + perf stat page-faults

 └── 网络慢 → ss -ant + ping + mtr

生产环境特别提醒

 ├── strace 有 ptrace 开销，用 -c 汇总模式

 ├── 火焰图只覆盖 on-CPU，IO 阻塞可用 off-CPU 补充

 └── perf 权限不够时确认 paranoid 值

这篇文章的价值在于把"排查流程"而不是"工具列表"作为主线——很多人都知道 perf 和 strace 各自怎么用，但不知道什么时候该用哪个、出了图该怎么读。它把这部分补齐了。