性能分析与优化方法论（六条排查线）

自顶向下 vs 自底向上 · 观测入口决策树 · CPU / 内存 / 锁 / GC / IO / 网络六条排查线 · eBPF 工具箱 · 优化决策链

场景问题

线上一个真实的排查现场往往是这样开局：

• P99 长尾：Grafana 上 P99 从 20ms 突刺到 300ms，均值只涨到 25ms——用平均值根本看不出。
• CPU 飙高：某台机 CPU 100%，其他机器 30%，负载均衡看着均匀——热点具体在哪个函数？
• 内存慢泄漏：RSS 每天涨 200MB，一周后 OOM——是分配率高还是真泄漏？
• 吞吐掉了：QPS 从 5000 掉到 3000，日志无异常——瓶颈是 CPU / IO / 锁 / GC 哪一段？
• 系统抖动：几十秒一次，无规律，指标看不到，玩家投诉——是 GC / 页回收 / 内核抢占 / 网络重传？
• 网络异常：请求慢，ping 正常，curl 正常，但业务就是慢——TCP retrans / 队头阻塞 / DNS？

性能分析的核心不是"这里能不能加个 cache"，而是先用方法论定位是哪一段慢，再决定用什么工具打透。方法论错了，工具再多都是白搭。

实现方案

一：方法论主线——自顶向下 vs 自底向上

两种正交路径，何时切换很重要：

USE 方法（Brendan Gregg）：针对资源（CPU / Mem / Disk / Net）：

• Utilization（利用率）
• Saturation（饱和度：排队长度）
• Errors（错误数）

RED 方法（Weave / Tom Wilkie）：针对请求（每个服务）：

• Rate（QPS）
• Errors（错误率）
• Duration（延迟分布，含 P50/P99）

二：观测入口决策树

线上出问题的六类症状 → 对应的首个排查动作：

三：六条排查线

① CPU 热点

判定信号：top 单核 100% / 火焰图某函数 >20% 帧占比 / P99 与 CPU 时间成正比。

工具箱：

on-CPU vs off-CPU：

• on-CPU 火焰图：谁在用CPU（真忙）
• off-CPU 火焰图：谁在等CPU / 等锁 / 等 IO（假闲）——症状模糊时更有用

伪共享（False Sharing）：不同核修改同一 cache line 内不同字段，导致 cache line 反复失效。信号：perf c2c 报告 HITM 高。修复：字段间用 [64]byte 填充或 alignas(64) 分离。

② 内存分配

判定信号：RSS 长期上涨 / P99 与 GC 频率正相关 / 分配率 (allocs/sec) 高。

核心区别：分配率高 ≠ 内存泄漏：

• 分配率高：短生命周期对象多，压 GC。优化方向：对象池、栈上分配、逃逸分析优化。
• RSS 增长（真泄漏）：长期不释放。排查方向：heap dump + 对比不同时间点的 Retained Size。
• RSS 增长（非泄漏）：堆碎片、大对象分配失败回退分配器、glibc arena 缓存。排查方向：jemalloc/tcmalloc 换分配器、MALLOC_ARENA_MAX 限 arena。

工具箱：

逃逸分析（Go）：go build -gcflags="-m" 看哪些变量从栈逃到堆。核心五因：变量地址被返回 / 接口装箱 / 闭包捕获 / 大对象 / 编译期不能确定大小。

③ 锁竞争

判定信号：QPS 上不去但 CPU 未满 / 单核 100% 其他核空闲 / mutex profile 显示某锁等待时间高。

工具箱：

锁优化决策链：

1. 能不锁就不锁：分片、无锁数据结构（sync.Map、Ring Buffer + CAS）
2. 锁粒度：粗锁 → 细锁（每 shard 一把）
3. 锁类型：Mutex → RWMutex（读多写少）→ Atomic / CAS（简单原语）
4. 协议：Lock-Free（CAS + ABA 防护）→ Wait-Free
5. RCU（Read-Copy-Update）：读永不阻塞

详见 concurrency 的锁选型章节。

④ GC-STW

判定信号：P99 突刺 / GC 频率高 / 堆大小锯齿 / STW 时长超预期。

入口指标（本篇只讲入口，详见 gc-stw）：

• P99 突刺周期与 GC 触发周期是否吻合？吻合 → GC 是元凶。
• GC 频率（Go: GOGC 影响，Java: 每分钟 Full GC 次数）
• 堆大小 & Allocation Rate（分配率过高 → GC 跟不上）
• STW 时长（Go 亚毫秒 / ZGC 亚毫秒 / G1 几十 ms / CMS 数百 ms）

联动排查动作：

• Go：GODEBUG=gctrace=1 + pprof allocs → 优化对象池
• Java：jstat -gc 1s + GC 日志 + gceasy.io 分析

⑤ IO / 系统调用

判定信号：CPU 空闲但请求慢 / iowait 高 / strace 看到大量 syscall。

工具箱：

慢盘 vs 慢文件系统：

• 慢盘：iostat 看 %util 长时间 100%、await 高。
• 慢文件系统：磁盘 %util 不高但业务慢，看 strace 里 open/close/fstat 占比——目录树大、inode 命中率低。

mmap 陷阱：

• Page fault 是同步阻塞的，一次未命中 = 一次磁盘 IO 卡当前线程；
• madvise(MADV_SEQUENTIAL/MADV_WILLNEED) 可预取；
• 大文件 mmap 撞 vsize 限制，MAP_ANONYMOUS 内存也不算 RSS 但算 vsize。

fsync / sync 频率过高 → 写吞吐骤降；批量写 + 定时 fsync 是常规优化。

⑥ 网络

判定信号：请求慢、ping 正常、curl 短请求正常但业务长连接慢 / netstat -s 看到 retrans 增长。

工具箱：

常见抓包场景：

• P99 长尾 + retrans 增长：接入网络质量或 buffer 不够，看 cwnd。
• connect 慢：SYN 丢或 backlog 打满，ss -lnt 看 Recv-Q。
• 业务耗时长，抓包快：问题在应用层（GC、锁、慢查询）。
• 业务耗时短，抓包慢：问题在网络传输链路。

详见 tcp-net 和 net-lowlatency-fullstack。

四：eBPF 工具箱（现代排障利器）

eBPF 是内核可编程的观测/追踪机制，无需改内核也无需重启。常用 one-liner：

# 进程调度延迟（等 CPU 的时间）
bpftrace -e 'kfunc:sched_wakeup { @start[args->p->pid] = nsecs; }
             kfunc:finish_task_switch { $delta = nsecs - @start[pid];
                                        @sched_lat = hist($delta / 1000);
                                        delete(@start[pid]); }'

# TCP 重传溯源（哪个连接在重传）
bpftrace -e 'kfunc:tcp_retransmit_skb { printf("retrans %d -> %s\n",
    args->sk->__sk_common.skc_num,
    ntop(args->sk->__sk_common.skc_daddr)); }'

# 系统调用延迟分布
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @start[tid] = nsecs; }
             tracepoint:raw_syscalls:sys_exit /@start[tid]/ {
                @syscall_lat[args->id] = hist(nsecs - @start[tid]);
                delete(@start[tid]); }'

# off-CPU 火焰图（谁在睡）
bpftrace -e 'kfunc:finish_task_switch { @off_cpu[kstack, ustack] = count(); }'

bcc-tools 常用工具：biolatency（块 IO 延迟）、tcplife（TCP 连接生命周期）、runqlat（运行队列延迟）、profile（采样调用栈）、funccount（函数调用计数）。

五：压测倒推系统瓶颈

压测数据不是"跑出个数字"，是"倒推系统瓶颈"（详见 loadgen-extreme）：

关键姿势：吞吐不线性 + 水位未满 = 被测饱和；水位满 = 发压机瓶颈。这是分辨"到底谁先撞墙"的唯一姿势。

六：优化决策链

四条铁律，按优先级：

1. 先测量后优化：无数据的优化 = 猜。做 A/B 对照实验，改前改后同一压测复现。
2. 先架构后微观：算法从 O(n²) 降到 O(n log n) 的收益 >> 循环内加 __builtin_prefetch。
3. 先热点后长尾：优化 20% 时间占比的热点 > 优化 1% 时间的长尾。
4. 先无损后有损：无损优化（对象池、批量 syscall、算法替换）走完再谈有损（降级 / 采样 / 精度让步）。

为什么这么做

• 为什么先方法后工具：工具永远学不完（perf / pprof / bpftrace / strace / ss / tcpdump 一大堆），但方法只有两条——自顶向下和自底向上。方法定了工具就位。反过来先学工具，出事时脑子会乱，不知道从哪里入手。
• 为什么六条排查线并列：真实事故的表现往往是"P99 长尾"这种症状级信号，但根因可能在六条线里任一条。不并列列出、不给决策树，排障就变成"经验英雄主义"（老兵靠感觉，新人抓瞎）。
• 为什么四条优化决策链有严格优先级：违反其中任一条都会踩坑——不测量就是猜、不看架构就是修修补补、不看热点就是白干、不做无损直接有损就是甩锅给业务。这四条是花钱买教训学到的。
• 为什么单独讲 eBPF：传统工具（perf / strace / gdb）多为侵入式（SIGSTOP 或 ptrace 会影响进程），生产环境不敢开。eBPF 是低开销、生产可用的观测机制，是现代排障的核心利器；不会 eBPF 相当于放弃一半排障能力。
• 为什么最后讲压测倒推：性能优化不能只在事后排障——压测本身就是"提前把瓶颈暴露出来"的手段。压测和排障用的是同一套工具箱，前者是主动、后者是被动。

为什么别的选择不行

• "凭经验优化，不看剖析"：改完发现瓶颈根本在别处，白干。先测量后优化不是原则，是铁律。
• "只看 CPU / 只看内存 / 只看网络"：真实事故经常跨多条排查线（比如 GC 引发 CPU 高，锁竞争引发 P99 长尾），单线思维会漏掉根因。
• "直接上 eBPF 打透一切"：eBPF 有学习曲线、低层信号需要经验解读。先走 USE/RED 定位到具体服务/接口，再上 eBPF 才有针对性。
• "追求 P50 优化 / 忽略 P99 长尾"：用户感知的是 P99（尾延迟），P50 优化不掉 P99 = 用户仍卡。
• "追求 P99 极致 / 放弃 P50 主流程"：反过来也一样坑——为 P99 加复杂缓存/预取，P50 主流程反而变慢，得不偿失。
• "直接上有损（降级/采样）跳过无损优化"：把技术问题甩给业务是最偷懒的做法。无损优化路走完再谈有损。

沉淀结论

• 方法先行：自顶向下（USE/RED 定位是哪一段）→ 自底向上（火焰图定位具体热点）；症状模糊时反过来。
• 观测入口决策树：错误率高 → 错误码分布；P99 长尾 → 单机 vs 多机；吞吐下降 → 下游 vs 资源；CPU 高 → on-CPU 火焰图；内存涨 → 分配率 vs RSS；抖动 → off-CPU 火焰图 + GC 日志。
• 六条排查线：CPU 热点 / 内存分配 / 锁竞争 / GC-STW / IO 系统调用 / 网络——各有工具箱与信号。
• eBPF 是现代排障利器：进程调度、TCP retrans、syscall 延迟、off-CPU 都能一行搞定，且生产可用。
• 压测倒推：吞吐不线性 + 水位未满 = 被测饱和；水位满 = 发压机瓶颈。
• 优化决策链四铁律：先测量后优化 / 先架构后微观 / 先热点后长尾 / 先无损后有损。
• 有损优化清单：降级 / 采样 / 精度让步 / 兜底——最后手段，且必须与业务协商。

记忆口诀

两条方法：自顶向下 USE/RED 定位 / 自底向上火焰图打透
USE 三要素：Utilization / Saturation / Errors（资源视角）
RED 三要素：Rate / Errors / Duration（请求视角）
六条排查线：CPU / 内存 / 锁 / GC / IO / 网络——各有工具箱
内存三看：分配率高 vs RSS 涨 vs 碎片——别混
锁优化四步：不锁 → 细粒度 → 换类型 → Lock-Free/RCU
四条决策链：测量 → 架构 → 热点 → 无损（再有损）
压测判据：不线性+未满=被测饱和 / 已满=发压机瓶颈
eBPF 四把刀：runqlat / tcpretrans / syscall lat / off-CPU

内容来源

综合整理。参考方向：Brendan Gregg 的 USE 方法与 Systems Performance 一书、Weave 的 RED 方法、火焰图工具链（FlameGraph GitHub）、Go pprof 官方文档、Java jstat/jmap/gceasy、eBPF 工具箱（bcc-tools、bpftrace）、以及站内 gc-stw / net-lowlatency-fullstack / tcp-net / loadgen-extreme / concurrency / observability 的方法论视角。

自测：合上资料能说清楚吗？