第13章案例研究

真实生产环境性能问题诊断

章节导读

方法论与工具只有在真实问题的淬炼中才会变成能力。本章是全书的收官：六个来自生产环境（或高度仿真的生产复现）的完整案例，覆盖性能工程师最常遭遇的六类问题形态——CPU 热点、I/O 饱和、容器资源限制、网络丢包重传、内存泄漏、GC 停顿。每个案例按统一的五段结构展开：现象描述（用户与监控看到了什么）、排查过程（用了哪些工具、每一步看到了什么、如何缩小范围）、根因分析（问题的完整因果链）、解决方案（修复动作与验证）、经验总结（可复用的模式与教训）。建议你阅读每个案例时先只看"现象描述"，停下来想一想"如果是我，第一步查什么"，再对照排查过程检验自己的思路——这种主动回忆式阅读比被动跟随的收益大得多。

为什么案例学习如此重要？第一，性能问题的表象与根因之间往往隔着好几层：用户说"页面卡"，可能是前端渲染慢、API 延迟高、数据库锁等待、宿主机 CPU 被邻居抢占、甚至 DNS 解析超时——排查的本质是在这棵巨大的因果树上高效剪枝，而剪枝的直觉只能从案例中积累。第二，工具的判读能力无法从手册获得：iostat 的 %util 在 NVMe 上为什么会说谎、火焰图上的"宽塔"什么时候是受害者而非凶手（如 sys 态的 futex_wait 宽塔指向的是锁争用而非内核慢）、vmstat 的 r 列高为什么可能不是 CPU 问题——这些判读的细微之处都藏在具体案例里。第三，真实排查几乎从不是教科书式的直线：会有错误的假设、走进死胡同、工具输出互相矛盾、问题"自己好了"又复发——本章尽量保留这些曲折，因为应对曲折的能力才是实战能力。

六个案例的选择覆盖了不同的资源维度与环境形态。案例一（Web 服务响应时间突增）是 CPU 剖析的经典应用：火焰图定位到一个出乎意料的热点——正则表达式回溯，展示了"代码层缺陷如何以系统层症状显形"。案例二（数据库查询变慢）走存储路径：iostat 与 biosnoop 揭示 I/O 饱和，根因是缺失索引导致的全表扫描，展示了"数据库问题的答案常常在 SQL 而不在存储"。案例三（容器内应用性能异常）是云原生时代的新经典：容器内一切指标"正常"但应用周期性卡顿，cgroups 追踪揭示 CPU quota throttling——配额限流的毛刺形态与诊断方法是容器环境的必修课。案例四（网络延迟抖动）用 tcpretrans 与 ss 定位重传，顺藤摸瓜找到网卡 ring buffer 溢出，展示网络问题的分层排查（应用 → TCP → IP → 驱动 → 网卡）。案例五（内存泄漏引发 OOM）综合 memleak 与内存火焰图追踪分配热点，根因是一个没有上限的本地缓存——"泄漏"未必是 bug，也可能是设计缺失。案例六（GC 停顿导致服务不可用）进入 JVM 运行时：JFR 与 async-profiler 分析 GC 日志，定位大对象分配触发的 Full GC，展示托管语言环境特有的性能问题形态。

这六个案例还隐含了一条方法论主线，即第 2 章的 USE 方法在实战中的展开。每个案例的排查都从"哪个资源、什么症状"的全局扫描开始（60 秒清单或等价物），先确定问题域（CPU？内存？I/O？网络？运行时？），再进入该域的专用工具做深度剖析（火焰图、biosnoop、runqlat、tcpretrans、memleak、GC 日志），最后用动态追踪做事件级的确认（谁、何时、多少）。这个"漏斗式"路径——从全局到局部、从计数器到事件、从系统到代码——是效率最高的排查拓扑，因为它每一步都把搜索空间砍掉一个数量级。反面教材是"随机漫步式"排查：一会儿看日志、一会儿重启服务、一会儿加机器，没有假设、没有测量、没有收敛。

阅读本章时请特别关注每个案例的"经验总结"部分，它们提炼出可迁移的模式：什么样的监控配置能让这类问题在用户投诉之前被发现（可观测性前置）、什么样的架构或代码习惯能预防这类问题（防御性设计）、以及排查中哪些弯路本可避免（工具熟练度）。性能工程的成熟度最终体现在两个数字上：MTTD（平均发现时间——问题发生到被察觉）与 MTTR（平均恢复时间——察觉到根因修复）。好的案例学习能把两者都压缩一个数量级。现在，让我们进入第一个案例：一个平静的下午，Web 服务的 P99 延迟突然翻了十倍。

核心概念

CPU 热点
I/O 饱和
cgroups 限制
网络重传
内存泄漏
GC 停顿

要点精析

案例一（上）：Web 服务响应时间突增的现象与排查路径。现象：某内容平台的 API 服务 P99 延迟从 80ms 突增到 800ms，P50 也从 15ms 涨到 60ms，错误率不变；延迟上升发生在一次常规发布后约 2 小时，且随流量增长持续恶化。监控的第一轮剪枝：QPS 与上一版本同期持平（排除流量因素）、下游依赖（数据库、缓存、第三方 API）的延迟全部正常（排除依赖因素）、实例的 CPU 使用率从 40% 爬升到 85%（锁定 CPU 域）、内存与 I/O 无异常。CPU 高的第二轮剪枝：mpstat 显示 %usr 为主（应用代码而非内核）、无 %steal（排除云邻居干扰）、各核均匀（排除单核热点/中断问题）。进入剖析：perf top 实时查看，发现一个正则匹配相关的符号占比异常；perf record -g -p PID 采样 60 秒生成折叠栈，火焰图上出现一座宽塔——约 55% 的采样落在正则引擎的回溯路径上，调用栈显示来自新发布版本引入的"用户输入清洗"中间件。关键疑点：为什么发布后 2 小时才恶化？检查发布记录与流量特征发现，新版本上线后爬虫流量恰好开始命中一个含特殊构造的 URL 参数——这个输入让新引入的正则进入了灾难性回溯。排查逻辑复盘：从"延迟高"到"CPU 高"到"%usr 高"到"具体函数"，四步每步都有工具证据，没有任何猜测。

案例一（下）：正则回溯的根因、修复与经验。根因分析：新中间件用了形如 (a+)+b 结构的正则做输入校验。这类含"嵌套量词"的正则在匹配失败时会产生指数级回溯：输入 aaaaaaaaaaaaaX（一串 a 后跟不匹配字符）会让引擎尝试 2^n 种分组切分方式才宣告失败。正常用户输入短且规整，匹配快速成功，开销可忽略——这就是发布后 2 小时无异常的原因；爬虫构造的长畸形参数触发失败路径，单次匹配耗时从微秒级爆炸到秒级，且此类请求随爬虫抓取量增长而增多，CPU 被逐渐吃满，所有请求（包括正常的）因排队而变慢——P50 与 P99 同时恶化正是"共享资源（CPU）饱和"的指纹，区别于"部分请求慢"的数据倾斜形态。修复：短期用特征规则拦截畸形参数 + 给正则匹配加超时（多数语言的正则库支持或可用线程超时包装）；根治是重写校验逻辑——用非回溯引擎（RE2、Rust regex，它们基于自动机理论保证线性时间）或改写为无嵌套量词的等价正则，并加入"恶意输入"测试用例（长串重复字符 + 失败结尾）进 CI。验证：修复后同流量下 CPU 回落到 35%，P99 恢复 75ms，火焰图上正则塔消失。经验总结：（1）任何处理外部输入的正则都要过一遍 ReDoS（正则拒绝服务）审查，嵌套量词与交替重叠是危险模式；（2）"发布后延迟恶化"优先做版本差分——对比新旧版本的火焰图（差分火焰图直接高亮新增的宽塔）；（3）CPU 饱和时 P50 与 P99 一起涨，这个形态学特征可以快速区分 CPU 瓶颈与锁/慢查询类瓶颈（后者通常只拉长尾部）。

案例二（上）：数据库查询变慢的现象与 I/O 诊断。现象：订单库的慢查询告警数量在业务低谷期（凌晨）反而激增，某报表类查询从平时的 2s 恶化到 40s+，同时在线交易接口的 P99 也被拖累（从 30ms 到 200ms）。第一轮剪枝：数据库服务器的 CPU 使用率不高（30%）、无锁等待告警（排除锁争用）、但 iostat -xz 1 显示数据盘的 %util 持续 95%+、r_await（读延迟）从平时的 0.5ms 恶化到 15ms、aqu-sz（队列深度）高达 30+——I/O 饱和实锤。第二轮深入：这是 SSD 阵列，%util 在多队列设备上有失真可能，用更细的工具确认——biosnoop（bcc）逐 I/O 追踪显示大量 4-16KB 的随机读、单 I/O 延迟毫秒级、且集中在报表查询的时间窗；biolatency 的延迟直方图呈双峰（缓存命中的快峰 + 设备排队的慢峰）。谁在读？用 iotop 与数据库侧的会话视图关联：报表查询的会话产生了每秒数千次的物理读。查询计划检查：EXPLAIN 显示该报表 SQL 对一张 5000 万行的表做全表扫描——优化器没有使用索引。为什么以前不慢？该表近期数据量翻倍，以前全表扫描的热数据还能大部分命中缓冲池，现在缓冲池命中率从 99% 跌到 60%，扫描的每一步都打到磁盘。

案例二（下）：缺失索引的根因、修复与经验。根因分析：完整因果链是——报表 SQL 的 WHERE 条件涉及一个组合列（status + created_at），建表时只建了单列索引 status，而该列区分度极低（90% 的行是同一个状态值），优化器评估走索引需要回表海量行，不如全表扫描，于是选择扫描；数据量小时扫描代价可被缓冲池吸收，数据量翻倍后缓冲池装不下工作集，扫描变成持续的磁盘随机读（读预取产生的大量 I/O），把 SSD 队列打满；I/O 设备是共享资源，在线交易的索引点查也需要设备服务，于是被报表的 I/O 洪流拖累——这解释了"报表慢 + 交易也慢"的连带现象，以及为什么发生在凌晨（报表定时任务集中运行）。修复：（1）立即措施——限制报表任务的并发与执行窗口（资源隔离，避免与在线交易争抢）；（2）根治——创建 (status, created_at) 组合索引，EXPLAIN 确认走索引后扫描行数从 5000 万降到 3 万，查询时间 40s → 300ms，物理读几乎归零；（3）配套——缓冲池命中率与慢查询纳入告警，数据量增长触发索引评审。验证：iostat 的 %util 回落到 20% 以下、r_await 恢复 0.3ms、biosnoop 显示报表时段的 I/O 量下降两个数量级、交易 P99 恢复 30ms。经验总结：（1）"数据库慢"的第一分层是 CPU/锁/I/O 三选一，iostat + 锁视图 + 数据库等待事件统计（如 MySQL 的 performance_schema、PG 的 pg_stat_activity）十分钟内可以定域；（2）I/O 饱和时永远追问"谁在产生 I/O、为什么"——存储层调优（换更快的盘）只是止痛，SQL 与索引才是病因；（3）缓冲池命中率是"数据量增长即将引发性能悬崖"的领先指标，值得设置趋势告警。

案例三（上）：容器内应用性能异常的现象与 cgroups 追踪。现象：某微服务迁移到 Kubernetes 后，P99 延迟出现规律性毛刺——每隔约 30-60 秒出现一批 500ms+ 的请求，P50 正常，CPU 使用率（监控面板显示）只有 60%，内存充足，节点整体负载不高。诡异之处：毛刺的周期性与"资源不足"的表象矛盾。第一轮剪枝：应用日志无异常、GC 日志正常（排除运行时停顿）、下游依赖延迟正常、同节点其他 Pod 无异常。节点级检查：mpstat 无单核热点、无 %steal、iostat 正常。陷入僵局后转向容器特有的观测面：cgroups。该 Pod 的 CPU limit 是 2 核（cpu.max 配额：每 100ms 周期最多 200ms CPU 时间）。读取 cgroup 的 cpu.stat：nr_throttled（被限流次数）与 throttled_time（累计限流时长）在持续增长——每次增长的时间点与延迟毛刺精确吻合。深入机制：该服务有 16 个工作线程（镜像沿用了物理机时代的配置，按 16 核机器设置），在 100ms 的配额周期开始时，16 个线程同时全速运行，约 60ms 内就烧完了 200ms 的配额（2 核 × 100ms），剩余 40ms 内所有线程被内核强制冻结（throttled）——请求恰好在冻结窗口内到达的，就经历 400-500ms 的额外延迟。监控面板显示 CPU 60% 是因为面板按"配额使用率"或分钟级平均计算，掩盖了周期内的瞬时爆发与冻结。

案例三（下）：CPU throttling 的根因、修复与经验。根因分析：cgroups CFS 带宽控制的机制是"周期配额"：cpu.cfs_period_us（默认 100ms）内允许消耗 cpu.cfs_quota_us 的 CPU 时间（limit 2 核即 200ms/周期）。应用线程数（16）远超配额核数（2）时，周期初的并行爆发会提前耗尽配额，触发全 cgroup 冻结直到下一周期——这产生两个后果：其一，延迟毛刺的周期性（与 100ms 周期及其倍数相关，宏观上表现为几十秒一批的规律毛刺，因为需要请求到达时刻与冻结窗口重叠才被观测到）；其二，CPU 利用率指标的欺骗性（冻结时间不计入使用率，分钟级平均进一步抹平）。这是容器环境最经典的"自伤型"性能问题：limit 是运维设的，线程数是开发设的，两者各自合理、组合致命。修复：（1）短期——把线程池规模改为与 CPU limit 匹配（2 核配额设 2-4 个工作线程），爆发消失，throttling 归零；（2）中期——评估移除 CPU limit 只保留 request（Kubernetes 社区的著名争论：CPU 是可压缩资源，limit 引发的 throttling 伤害常大于其隔离收益，Google/GKE 的最佳实践是 CPU 不设 limit 或设大 limit）；（3）长期——把 container_cpu_cfs_throttled_periods_total（cAdvisor 指标）纳入告警，JVM/Go 运行时配置感知容器配额（-XX:ActiveProcessorCount、GOMAXPROCS 的 automaxprocs）。验证：修复后 cpu.stat 的 nr_throttled 停止增长、P99 毛刺消失、相同 QPS 下延迟分布整体收窄。经验总结：（1）容器内"资源充足但周期性卡顿"的第一嫌疑就是 throttling，cat cpu.stat 十秒钟出结论；（2）容器内的 nproc/top 看到的是节点视图，配额才是真实约束——运行时与线程池配置必须以配额为准；（3）监控必须采集 cgroup 级指标（throttling、PSI），节点级与应用级指标之间存在容器特有的观测盲区。

案例四（上）：网络重传导致延迟抖动的现象与定位。现象：跨可用区的 RPC 调用 P99.9 延迟间歇性出现 200ms+ 的尖刺（正常 2ms），频率约每分钟数次，无规律；应用与系统层检查全部正常——两端 CPU、内存、I/O 均无压力，TCP 连接数正常。200ms 这个数字本身是线索：它接近 Linux TCP 的最小重传超时（RTO_MIN = 200ms），强烈暗示"丢包 → 重传 → RTO 等待"的机制（快速重传只需一个 RTT，而 RTO 超时重传要等满 200ms——尖刺恰好 200ms+ 说明丢的是尾部包或 ACK，触发不了三次重复 ACK 的快速重传路径）。验证假设：tcpretrans（bcc，基于 eBPF 追踪 tcp_retransmit_skb 内核函数）运行 10 分钟，捕获到数十次重传事件，时间戳与延迟尖刺一一对应，且输出显示部分事件带 [TLP]（Tail Loss Probe，尾丢包探测）标记。丢包在哪一层？分层排查：两端 netstat -s / nstat 显示发送端 TcpRetransSegs 增长而接收端无乱序重排计数异常；ping 与 mtr 长测无丢包（ICMP 低速流量不触发问题）；检查接收端网卡计数 ethtool -S：rx_missed_errors 与 rx_no_buffer_count 在持续增长——网卡 ring buffer 溢出丢包的铁证。为什么监控没发现？丢包率只有十万分之几，带宽与 pps 监控的粒度完全看不见，只有 RTO 级的延迟尖刺暴露了它。

案例四（下）：ring buffer 溢出的根因、修复与经验。根因分析：接收端网卡的 ring buffer（网卡到内核的硬件队列）深度是默认值 256，而该机器承接多个服务的流量；当瞬时突发（多个大响应同时到达，或 GC 停顿后积压的 ACK/数据涌入）超过内核收包线程（softirq）的即时处理速度，ring buffer 满，网卡直接丢弃后续到达的包——rx_missed_errors 计数。被丢的包若是数据尾部，发送端等不到 ACK 又凑不齐三个重复 ACK，只能等 RTO（200ms+）超时重传，这就是尖刺的完整因果链：突发流量 → ring 溢出 → 尾丢包 → RTO 重传 → 应用可见的 200ms 尖刺。注意丢包发生在接收端硬件层，所以两端内核的 IP/TCP 错误计数都"干净"，只有网卡统计与 tcpretrans 的发送端视角能看见。修复：（1）ethtool -G eth0 rx 4096 把 ring buffer 加深 16 倍，吸收突发；（2）检查并优化收包路径——开启 GRO（大包聚合减少协议栈处理次数）、确认多队列 RSS 生效且中断亲和分散（避免单核 softirq 成为处理瓶颈，用 mpstat 的 %soft 列验证各核均衡）；（3）评估 RPS 作为软件兜底。验证：修复后 rx_missed_errors 停止增长、tcpretrans 连续 24 小时零事件、P99.9 尖刺消失。经验总结：（1）延迟尖刺的数值特征是重要的第一线索——200ms 想到 TCP RTO、几十毫秒的周期毛刺想到容器 throttling、秒级规律停顿想到 GC 或 cron；（2）网络丢包排查必须走完整分层：应用（超时/重试计数）→ TCP（重传、乱序：nstat/ss -ti）→ IP（丢包计数）→ 驱动/网卡（ethtool -S 的 ring 溢出、错包）→ 交换机（端口 discard，需要网络团队配合）；（3）低比例丢包对延迟的伤害远大于对吞吐的伤害（一个丢包 = 一次 RTO 或窗口减半），高 P99.9 要求的系统必须把"零丢包"作为网络 SLO 监控 ethtool 计数。

案例五（上）：内存泄漏引发 OOM 的现象与追踪。现象：某 Java 混合架构中的原生 sidecar 服务（C++ 编写）运行 3-5 天后被内核 OOM killer 杀死（dmesg 有记录），重启后恢复，周而复始；监控显示 RSS 以每天约 800MB 的速度线性增长，而应用自身的"活跃对象数"指标平稳。第一轮剪枝：RSS 线性增长 + 应用逻辑指标平稳 = 典型的泄漏形态（区别于"缓存按设计增长"的收敛曲线与"负载相关波动"的周期曲线）。确认泄漏域：/proc/PID/smaps_rollup 显示增长全部在匿名内存（heap 段），文件映射与栈稳定——堆泄漏。追踪分配：由于是 C++ 服务，用 memleak（bcc，基于 uprobes 挂钩 malloc/free 或 USDT 探针）采样 10 分钟，输出"分配了但未释放"的调用栈聚合——一座清晰的栈占了未释放量的 85%：某缓存模块的 put 路径。交叉验证：用 jemalloc 的堆剖析（LD_PRELOAD + MALLOC_CONF=prof:true）在间隔 1 小时的两个时间点 dump 剖面，jeprof --base 差分显示同一函数的分配增量占绝对主导——两种独立工具指向同一位置，证据链闭合。代码审查确认：该模块实现了一个"会话缓存"，用哈希表存放会话对象，设计了 TTL 字段但清理线程在两个月前的一次重构中被误删——只进不出。

案例五（下）：缓存无上限的根因、修复与经验。根因分析：这是一个"设计缺失型泄漏"而非"代码 bug 型泄漏"——没有野指针、没有忘记 free 的显式错误，而是缓存的生命周期管理不完整：有插入（put）、有过期标记（TTL 字段），但没有淘汰执行者（清理线程被删）也没有容量上限（无 LRU/LFU 驱逐）。每个会话对象约 2KB，日活会话 40 万个，每天净增约 800MB，与监控曲线精确吻合——根因确认的最后一块拼图是"泄漏速率与业务量的定量匹配"，这一步能排除巧合。为什么 3-5 天才 OOM？容器内存 limit 4GB，基础占用 1.5GB，泄漏空间 2.5GB ÷ 800MB/天 ≈ 3 天。修复：（1）立即——恢复清理线程并加监控（缓存条目数、内存占用两个指标 + 告警）；（2）根治——给缓存加容量上限与 LRU 驱逐（用成熟的缓存库替代手写哈希表，如 folly 的 EvictingCacheMap 或带 maxmemory 的嵌入式 KV），"无上限的进程内缓存"列入代码审查黑名单；（3）防御——TTL 与容量双保险，即使清理逻辑再次失效，容量上限也能兜底。验证：修复后 72 小时 RSS 曲线水平（有锯齿波动但无趋势），缓存条目数稳定在上限附近。经验总结：（1）泄漏排查的标准工具链按语言分：原生（memleak/jemalloc prof/valgrind——valgrind 开销大仅限测试环境）、JVM（jmap 堆转储 + MAT 的支配树分析、NMT 区分堆内外）、Go（pprof 的 heap profile）；（2）"两个独立工具交叉验证 + 泄漏速率与业务量定量吻合"是根因确认的黄金标准，避免修错地方；（3）任何进程内缓存必须回答三个问题：上限是什么、淘汰策略是什么、命中率怎么观测——答不上来就是未来的 OOM 事故。

案例六（上）：GC 停顿导致服务不可用的现象与 JVM 诊断。现象：某电商的 Java 服务在促销高峰出现间歇性完全无响应——健康检查超时、上游熔断触发、部分实例被摘除，每次持续 3-8 秒，高峰期内发生十余次；实例的 CPU 使用率在停顿时刻反而下降（线程都停了），堆内存使用率呈"锯齿爬到顶 → 骤降"的形态。第一轮定域：GC 日志（-Xlog:gc*）显示停顿时刻全部对应 Full GC 事件，单次 3-8 秒，且 Full GC 后老年代只回收了不到 20%（回收效率低 = 老年代里都是活对象，被迫反复 Full GC）。为什么老年代爆满？用 jmap -histo:live 与堆转储分析（MAT）：占据老年代 70% 的是一种促销活动的商品列表对象——单次请求会把最多 10 万个商品 DTO 反序列化到内存做过滤排序。对象分配的年龄分析：这些大列表单次就有数百 MB，超过 G1 的 region 大小阈值被当作 Humongous Object 直接在老年代分配——绕过了年轻代的正常晋升流程，高峰期每秒数个这样的请求，老年代以肉眼可见的速度填满，触发 Full GC 风暴。辅助验证：async-profiler 的 alloc 模式（--alloc 采样分配调用栈）火焰图显示 85% 的分配字节数来自该反序列化路径；JFR（Java Flight Recorder）的 Allocation Outside TLAB 事件同样指向巨型数组分配。

案例六（下）：大对象分配的根因、修复与经验。根因分析：完整因果链是——促销接口的实现假设"商品列表不大"，用一次性全量加载 + 内存过滤的写法；促销活动使列表膨胀到 10 万级，单次请求分配数百 MB 的巨型对象数组；G1 收集器对超过 region 一半大小的对象走 Humongous 分配路径，直接进老年代且回收时机受限（只在并发周期或 Full GC 时处理）；高峰期巨型对象持续涌入，老年代占用快速逼近 IHOP（Initiating Heap Occupancy Percent）阈值，并发标记周期来不及完成就被分配速度追上（to-space exhausted / evacuation failure），退化为单线程/多线程的 Full GC——STW（Stop-The-World）数秒，服务完全冻结；健康检查超时触发摘除，剩余实例承接更多流量、分配更快、Full GC 更频繁——雪崩式恶化。CPU 使用率在停顿时下降是 STW 的典型指纹（所有应用线程暂停，只有 GC 线程工作，若 GC 线程数少则总 CPU 反而下降）。修复：（1）立即——促销接口加分页与流式处理（每批 1000 条过滤后丢弃，峰值内存从数百 MB 降到数 MB）、上游限流保护；（2）中期——大列表查询下推到存储层（数据库/搜索引擎做过滤排序，应用只取 TopN）、DTO 瘦身（只反序列化需要的字段）；（3）防御——G1 参数调优（增大 region 尺寸 -XX:G1HeapRegionSize=32m 让多数对象不再落入 Humongous 路径、调低 IHOP 提前启动并发标记）、分配速率与大对象分配纳入监控（JFR 常驻开启，开销 <1%）。验证：修复后高峰期零 Full GC、Young GC 停顿稳定在 50ms 内、P99 恢复。经验总结：（1）Java 服务"周期性秒级冻结 + CPU 反降"几乎必是 GC 问题，GC 日志是第一现场，必须常开（-Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=20m）；（2）诊断三件套的分工：GC 日志看停顿形态与频率、jmap/MAT 看堆里是什么、async-profiler alloc/JFR 看谁在分配——"是什么"与"谁干的"要分别回答；（3）Humongous 分配是 G1 特有的陷阱，大数组/大列表操作要意识到 region 阈值的存在；（4）GC 调优的优先级永远低于分配行为优化——少分配比会回收重要得多。

代码示例

perf top -p 12345
/* 实时热点：先粗看哪个符号占比异常 */
perf record -F 99 -p 12345 -g -- sleep 60
/* 99Hz 采样 60 秒，-g 采集调用栈（99 而非 100：避免与定时任务共振） */
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > cpu.svg
/* 生成 CPU 火焰图：宽度即占比，找最宽的塔 */
perf record -F 99 -p 12345 -g -- sleep 60 && perf script | ./stackcollapse-perf.pl > after.folded
/* 修复后再次采样，与修复前的 folded 文件做差分 */
./difffolded.pl before.folded after.folded | ./flamegraph.pl > diff.svg
/* 差分火焰图：红色为新增/变宽（恶化），蓝色为消失/变窄（改善） */
grep -c "catastrophic" access.log
/* 配合访问日志确认畸形输入的来源与时间分布 */

案例一的完整工具链：从实时粗查到差分验证。perf top 是"CPU 高了先看一眼"的零准备工具，它以 curses 界面实时刷新符号级占比，几秒内就能发现异常热点（本案例中正则引擎符号的占比一眼可见）；但 perf top 没有调用栈上下文，确认热点后要用 perf record -g 采集带栈样本。-F 99 的采样率选择有讲究：99Hz 意味着每核每秒 99 个样本、开销约 1%，且刻意避开 100 这个整数——防止采样与应用的周期性行为（100ms 定时任务）锁相产生偏差。火焰图判读的三个要点：横轴是字母序不是时间序（不要误读为执行顺序）、宽度是唯一重要的量（占比）、纵轴是调用深度（栈顶是正在消耗 CPU 的函数）。本案例的火焰图上，正则回溯路径的塔占 55% 宽且栈顶集中在回溯引擎内部函数——"宽塔 + 栈顶在库内部"的组合指向"应用调用了病态输入的库函数"而非"库本身慢"。差分火焰图是修复验证的最直观形式：修复前后各采一次 folded 文件，difffolded 合并后着色渲染，正则塔整体变蓝（消失）即视觉化的"修复生效"证据——这比只看 P99 数字更有说服力，因为它证明了因果机制而不只是相关性。生产环境注意：perf record 的开销与采样率成正比，99Hz 下通常 <1%，可安全用于线上；符号解析需要应用带调试符号或 debuginfo 包，JVM/Go 等运行时语言需要对应的 perf map 支持（-XX:+PreserveFramePointer 与 perf-map-agent、Go 1.18+ 的内建支持）。

iostat -xz 1
/* 第一轮：确认 I/O 饱和——%util、r_await、aqu-sz 三指标 */
biosnoop
/* bcc/eBPF：逐 I/O 事件流——PID、进程名、设备、扇区、大小、延迟 */
biolatency 10 6
/* I/O 延迟直方图：10 秒一个直方图共 6 个，观察双峰形态 */
biotop
/* I/O 界的 top：按进程聚合的 I/O 速率排行 */
pidstat -d 1
/* 按进程的 I/O 吞吐（kB_rd/s、kB_wr/s），与数据库会话关联 */
mysql> SELECT * FROM sys.statements_with_full_table_scans ORDER BY no_index_used_count DESC LIMIT 5;
/* MySQL sys 库：全表扫描语句排行——直接定位缺索引的 SQL */
mysql> EXPLAIN SELECT ... ;
/* 查询计划：type=ALL 即全表扫描，rows 是预估扫描行数 */

案例二的存储诊断工具链，展示"系统层证据 → 数据库层归因"的两段式排查。iostat -xz 1 的三指标判读：%util 高说明设备忙（NVMe 上需交叉验证）、r_await 是读请求从进队列到完成的平均时间（SSD 正常 <1ms，15ms 说明严重排队）、aqu-sz 是平均队列深度（30+ 意味着请求大量积压）——三者共同构成 I/O 饱和的完整证据。但 iostat 只回答"设备忙"，不回答"谁、什么样的 I/O"，这正是 eBPF 块层工具的价值：biosnoop 输出每个 I/O 的事件流（时间戳、进程、设备、起始扇区、大小、延迟、是否命中页缓存），本案例中它揭示了"大量 4-16KB 随机读、来自 mysqld 进程、延迟毫秒级"的微观形态——随机小读是索引缺失/全表扫描的典型 I/O 指纹（顺序大读则指向扫描类正常行为或预读）。biolatency 的直方图把延迟分布可视化：双峰形态（快峰 = 设备正常服务或缓存命中，慢峰 = 排队后的服务）是饱和的教科书特征，比平均值信息量大得多。biotop 与 pidstat -d 完成"进程归因"。系统层证据齐备后，进入数据库层回答"为什么产生这种 I/O"：MySQL 的 sys.statements_with_full_table_scans 视图直接按"未用索引的扫描次数"排行 SQL（PostgreSQL 对应 pg_stat_statements 的 shared_blks_read 排序 + seq_scan 计数），EXPLAIN 确认执行计划——type=ALL（全表扫描）与 rows=5000 万就是判决书。这套两段式路径的普适性：任何"存储慢"问题都要走完"设备层饱和证据 → 进程归因 → 应用/SQL 层动机"三步，只停在第一步就会得出"换更快的盘"的止痛式结论。

cat /sys/fs/cgroup/cpu/kubepods/pod-xxx/cpu.stat
/* cgroups v1 路径；v2 为 /sys/fs/cgroup/kubepods.slice/.../cpu.stat
   输出：nr_periods、nr_throttled、throttled_time——限流三指标 */
cat /sys/fs/cgroup/cpu/kubepods/pod-xxx/cpu.cfs_quota_us
cat /sys/fs/cgroup/cpu/kubepods/pod-xxx/cpu.cfs_period_us
/* 配额与周期：quota/period = 等效核数（200000/100000 = 2 核） */
bpftrace -e "tracepoint:cgroup:cgroup_reclaim_start { printf(\"reclaim %d\n\", pid); }"
/* 追踪 cgroup 级内存回收事件（内存 limit 压力的信号） */
runqlat -p 12345 10
/* 调度队列延迟直方图：throttling 会表现为异常的长尾 */
kubectl top pod mypod --containers
/* K8s 视角的资源使用（注意：分钟级平均，看不见周期内爆发） */
cat /proc/pressure/cpu
/* PSI：some avg10 高而 CPU 使用率不高 = 被限流或调度延迟的强信号 */

案例三的容器观测工具链，核心是打通"应用症状 ↔ cgroup 计数器"的证据链。cpu.stat 的三个字段是诊断 throttling 的全部所需：nr_periods 是经历的配额周期总数、nr_throttled 是被限流的周期数、throttled_time（v1，纳秒）或 throttled_usec（v2）是累计冻结时长——判断方法是看增量而非绝对值：间隔 60 秒读两次，nr_throttled 增长即"正在被限流"，throttled_time 增量除以间隔即"冻结时间占比"。本案例中每 100ms 周期有 40ms 冻结，占比 40%，与延迟毛刺的幅度吻合。cpu.cfs_quota_us 与 cfs_period_us 给出配额的精确语义（quota/period = 等效核数），这是判断"线程数是否超配"的依据——16 线程对 2 核配额就是 8 倍超配。cgroups v2 的路径与文件名不同（cpu.max 一个文件包含"配额 周期"两个值，memory.max 替代 limit_in_bytes），Kubernetes 1.25+ 默认 v2，排查脚本要兼容两代。PSI（/proc/pressure/cpu 与 cgroup 内的 cpu.pressure）是更现代的替代信号：它直接度量"任务因等 CPU 而停滞的时间比例"，throttling 会推高 some avg10——且 PSI 在 cgroup 级别可用，比解析 cpu.stat 更适合告警管道。runqlat 从调度延迟视角交叉验证：正常的调度延迟是微秒级，被冻结的线程恢复运行时表现为数百毫秒的"调度延迟"长尾。经验法则：容器环境的延迟毛刺排查，cpu.stat 与 cpu.pressure 应该和 GC 日志并列第一批检查项——两者的检查成本都是秒级。

tcpretrans
/* bcc/eBPF：实时重传事件流——时间、PID、源目地址端口、序列号、状态 */
tcpretrans -l
/* -l 包含 TLP（尾丢包探测）事件：尾丢包的专门信号 */
tcplife
/* 每条 TCP 连接的生命周期汇总：建连时间、存活时长、收发字节 */
ss -ti dst 10.0.0.5
/* 单连接详情：cwnd、rtt、retrans、rto——尖刺时刻抓现场 */
nstat -az | grep -iE "retrans|loss|recovery"
/* 全局 TCP 计数：重传段、丢包恢复、TLP 次数 */
ethtool -S eth0 | grep -iE "miss|drop|no_buffer|fifo"
/* 网卡硬件计数：rx_missed_errors/rx_no_buffer_count = ring 溢出铁证 */
ethtool -g eth0
/* 查看 ring buffer 当前值与硬件上限 */
ethtool -G eth0 rx 4096
/* 加深接收 ring buffer */
tc qdisc add dev eth0 root netem loss 0.01%
/* 实验环境复现：注入万分之一丢包验证症状一致性（生产禁用） */

案例四的网络诊断工具链，按"TCP 层证据 → 分层定位 → 硬件计数"组织。tcpretrans 基于 eBPF 挂钩内核的 tcp_retransmit_skb 函数，每个重传事件实时输出五元组与序列号——它的价值是把"疑似丢包"变成"确凿的重传事件流"，且开销近乎为零可长期运行；-l 参数纳入 TLP（Tail Loss Probe）事件尤其关键：TLP 是内核为尾丢包设计的探测机制（发一个探测包触发快速恢复，避免等满 RTO），tcpretrans 输出中的 [TLP] 标记直接告诉你"这是尾丢包场景"——本案例正是靠它区分了"随机丢包"与"尾丢包"。ss -ti 是尖刺时刻的现场抓拍工具：输出中的 retrans 字段（当前/累计重传）、rto 值（当前重传超时）、cwnd（拥塞窗口是否被砍半）构成单连接的完整状态。nstat 的全局计数（TcpExtTCPLostRetransmit、TcpExtTCPTimeouts、TcpExtTCPTLPRecovery）用于趋势对比与两端交叉验证。分层定位的关键一跳是 ethtool -S：网卡驱动暴露的硬件统计中，rx_missed_errors（Intel 系 rx_no_buffer_count）增长意味着"包到达网卡但 ring buffer 无空位，硬件直接丢弃"——这是接收端硬件层丢包的确凿证据，与 IP/TCP 层计数无关（包根本没进内核协议栈）。ethtool -g 显示 ring 的当前/最大深度（默认常是 256/512，最大 4096），-G 调整立即生效。最后的 netem 命令是方法论示范：在实验环境注入与生产症状等价的故障（0.01% 丢包），验证"注入后症状复现、修复后症状消失"——故障注入是根因确认的最强手段，把相关性升级为可复现的因果性。

memleak -p 12345 10 5
/* bcc：追踪 10 秒、每 5 秒输出一次"已分配未释放"的调用栈聚合 */
memleak -p 12345 -a
/* -a 显示分配大小分布，区分"大量小对象"与"少数大对象"泄漏 */
cat /proc/12345/smaps_rollup
/* 进程内存汇总：Rss、Anonymous、Swap——确认增长在哪个段 */
pmap -x 12345 | sort -k3 -n -r | head -20
/* 按大小排序的内存段列表：定位异常增长的映射 */
LD_PRELOAD=/usr/lib/libjemalloc.so MALLOC_CONF="prof:true,lg_prof_interval:30" ./service
/* jemalloc 堆剖析：每 1GB 分配自动 dump 剖面 */
jeprof --base=heap.1.heap --pdf ./service heap.2.heap > leak.pdf
/* 两个时间点的剖面差分：持续增长的分配栈即泄漏源 */
jmap -histo:live 12345 | head -30
/* JVM：存活对象直方图（触发一次 Full GC 后统计） */
jcmd 12345 GC.heap_dump /tmp/heap.hprof
/* JVM 堆转储，用 MAT 分析支配树（Dominator Tree） */

案例五的内存泄漏追踪工具链，覆盖原生与 JVM 两个世界。原生侧的第一层是"确认泄漏存在与定位内存段"：smaps_rollup 给出进程内存的权威汇总（比 top 的 RES 更细：Anonymous 是堆与匿名映射、File-backed 是文件映射），间隔采样对比即增长曲线；pmap -x 按段列出，能区分"主堆增长"（malloc 泄漏）与"某个大映射增长"（mmap 泄漏）。第二层是"归因到调用栈"：memleak 用 eBPF 挂钩 malloc/free（ uprobes 或 USDT），在采样窗口内聚合"分配了但窗口结束时还没释放"的栈——注意它的语义是"疑似泄漏"（窗口内正常的长生命周期分配也会出现），所以要多次采样看"持续出现的栈"才是真泄漏；-a 的大小分布帮助判断泄漏形态（大量 2KB 对象 = 会话/请求级泄漏，少数 GB 级 = 缓冲区泄漏）。jemalloc prof 是更精确的替代：采样式分配剖析开销 <2% 可生产常开，两个时间点的 --base 差分直接输出"这段时间净增长的分配栈排行"——本案例中差分结果 85% 指向缓存 put 路径，与 memleak 交叉验证闭合证据链。JVM 侧的对应流程：jmap -histo:live 快速看"什么类的实例最多"（:live 触发 Full GC 排除垃圾干扰，生产慎用——会 STW），确认嫌疑类后 GC.heap_dump 导出 hprof 用 MAT 分析：支配树（Dominator Tree）显示"谁持有这些对象"、Path to GC Roots 显示"为什么没被回收"——持有链的顶端就是泄漏点。工具选择的总原则：先无侵入（smaps/计数器）确认形态，再采样式（memleak/prof）归因，最后侵入式（heap dump）精确定位——开销逐级上升，范围逐级收窄。

jcmd 12345 JFR.start name=rec settings=profile duration=120s filename=/tmp/rec.jfr
/* 启动 JFR 录制：profile 配置开销约 1-2%，生产可用 */
jfr print --events jdk.GCPhasePause,jdk.GarbageCollection,jdk.OldObjectSample /tmp/rec.jfr
/* 打印 GC 停顿与老年代对象采样事件 */
jcmd 12345 GC.heap_info
/* 各代/各 region 的占用概况：快速判断老年代压力 */
jmap -histo:live 12345 | head -20
/* 存活对象直方图：定位占堆主导的类 */
./profiler.sh -d 60 -e alloc -f alloc.html 12345
/* async-profiler 分配火焰图：按分配字节数归因到调用栈 */
./profiler.sh -d 60 -e wall -t -f wall.html 12345
/* wall-clock 模式 + 按线程分组：观察 STW 期间线程状态 */
tail -f gc.log | grep -E "Pause Full|Evacuation Failure|to-space"
/* GC 日志实时监控：Full GC 与疏散失败是红色警报 */
java -Xlog:gc*,gc+heap=debug:file=gc.log:time,uptime,level,tags:filecount=5,filesize=20m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dumps -jar app.jar
/* 生产 JVM 的标准观测配置：GC 日志常开 + OOM 自动堆转储 */

案例六的 JVM 诊断工具链，按"常驻观测 → 事件录制 → 分配归因"三层组织。最底层是启动参数里的常驻观测：-Xlog:gc* 的 GC 日志必须常开（滚动配置 filecount/filesize 防止磁盘写满，开销可忽略），它是所有 GC 问题的第一现场——本案例中"Pause Full 3-8s + 回收率 <20%"的形态直接从日志读出；HeapDumpOnOutOfMemoryError 保证 OOM 时刻的堆现场自动留存（事后分析的唯一机会，很多团队漏配这一项）。第二层是 JFR（Java Flight Recorder）：JDK 11+ 免费开放，settings=profile 的开销约 1-2%，支持生产环境按需录制或常驻低开销录制（settings=default 约 <1%）；它记录的事件覆盖 GC 各阶段耗时、TLAB 内外分配、锁竞争、线程状态——jfr print 或 JMC（Mission Control）图形化分析。本案例的关键事件是 Allocation Outside TLAB：JVM 的小对象分配走线程本地缓冲（TLAB），超过 TLAB 的大对象直接走慢路径分配——该事件频繁出现且尺寸巨大，就是"大对象分配"的直接证据。第三层是 async-profiler 的 alloc 模式：按分配字节数（而非次数）采样归因到调用栈，火焰图宽度 = 分配量占比，85% 宽度指向反序列化路径即完成"谁在分配"的回答；wall 模式（-e wall）按真实时间采样所有线程（包括睡眠/阻塞的），配合 -t 按线程分组，可以观察 STW 窗口内应用线程的集体暂停形态——这是 CPU 火焰图看不到的视角（STW 时应用线程不消耗 CPU，CPU 火焰图上它们是"消失"的）。工具分工总结：GC 日志回答"停顿何时发生、什么类型"，JFR/堆转储回答"堆里是什么"，async-profiler alloc 回答"谁在往里放"——三问齐答，根因自现。

实验笔记

实验十三：搭建故障注入实验室，亲手复现并诊断六个案例。

实验目标：（1）在可控环境中复现本章六类问题，把"读案例"变成"破案例"；（2）为每类问题建立自己的"症状 → 工具 → 证据"速查卡；（3）练习故障注入技术——它是验证根因与演练诊断的最强手段。

环境准备：一台 4 核 8GB Linux 虚拟机（或 Kind/Minikube 集群用于案例三），安装：perf 与 FlameGraph 脚本（git clone brendangregg/FlameGraph）、bcc-tools 与 bpftrace（apt install bpfcc-tools bpftrace）、sysstat、ethtool、stress-ng、tc（iproute2）、JDK 17+ 与 async-profiler、wrk2。准备三个靶机应用：（a）一个含"病态正则"接口的 Web 服务（如 Python Flask，接口对输入参数跑 (a+)+b 型正则）；（b）一个含无上限缓存的服务（每请求往全局 dict 塞一个 2KB 对象，永不删除）；（c）一个 Java 服务（Spring Boot，含"一次性加载大列表并排序"的接口，列表大小由请求参数控制）。

案例一复现（CPU 热点）：用 wrk2 以 500 RPS 打靶机 a 的正常参数（短字符串），记录基线 P99 与 CPU；再混入 5% 的畸形参数（30 个 a 后跟 X），观察 P99 爆炸与 CPU 爬升。用 perf top 找到正则符号，perf record + 火焰图确认宽塔。修复演练：给正则加输入长度限制，重测验证火焰图变化。用 difffolded 生成修复前后的差分火焰图。

案例二复现（I/O 饱和）：MySQL 建一张 500 万行表（sysbench prepare），跑一个 WHERE 低区分度列的查询（无有效索引），同时用 iostat -xz 1、biosnoop、biolatency 观察 I/O 形态（大量随机读、延迟直方图右移）。CREATE INDEX 后重跑，对比三个工具的输出变化。附加：用 pidstat -d 确认 I/O 归属 mysqld。

案例三复现（容器 throttling）：Kind 集群部署一个 CPU 密集服务，limit 设 500m（半核）但应用开 8 个忙线程。用 wrk2 打压，观察延迟毛刺；kubectl exec 进容器读 cpu.stat 确认 nr_throttled 增长；把线程数改为 1，验证 throttling 归零。对比 cgroup v1/v2 的 cpu.stat 路径与字段差异。

案例四复现（网络丢包）：两台虚拟机（或同机两个网络命名空间 ip netns）互打流量。接收端用 tc netem loss 0.5% 注入丢包（或用 ethtool -G 把 ring 调到最小 + 突发流量制造真实溢出），发送端运行 tcpretrans 捕获重传事件，ss -ti 观察 rto 与 cwnd，对比注入前后 P99.9 的 200ms 级尖刺。移除注入验证恢复。

案例五复现（内存泄漏）：运行靶机 b，用 while 循环持续请求。每 5 分钟记录 smaps_rollup 的 Rss/Anonymous，画出线性增长曲线；用 memleak -p 采样 60 秒找到未释放栈；LD_PRELOAD jemalloc + prof 做两个时间点的差分验证。修复演练：给缓存加 maxlen 的 LRU（如 Python 的 functools.lru_cache 或手写 OrderedDict 淘汰），验证 RSS 曲线变平。

案例六复现（GC 停顿）：运行靶机 c，JVM 堆设小（-Xmx512m -XX:+UseG1GC -Xlog:gc*），用脚本并发请求"大列表"接口（列表 50 万元素）。观察 GC 日志中 Humongous 分配与 Full GC 的出现、服务的秒级冻结（curl 计时验证）；jcmd JFR.start 录制并用 jfr print 查看 Allocation Outside TLAB 事件；async-profiler -e alloc 生成分配火焰图定位大对象来源。修复演练：改为流式/分页处理或调大 G1HeapRegionSize，验证 Full GC 消失。

总结产出：为六类问题各写一张速查卡（症状指纹 / 第一批工具 / 确认证据 / 常见根因 / 修复模式），合并成你的"性能急救手册"。这份手册的价值会在你第一次独立处理生产事故时兑现。

进阶挑战：（1）把六个注入场景写成 docker-compose + 脚本的一键演练环境，供团队培训使用；（2）为每个场景配置 Prometheus 告警规则（如 nr_throttled 增量、rx_missed_errors 增量、RSS 斜率），验证"告警先于用户投诉"；（3）混沌工程化——用 Chaos Mesh 或 Gremlin 把注入实验变成生产环境的常态化演练（Game Day）。

第13章 案例研究