第13章 案例研究

生产环境 BPF 实战诊断

章节导读

前面十二章，我们系统地走过了 BPF 性能工具的完整知识版图：从 BPF 的技术原理与生态，到 CPU、内存、磁盘、文件系统、网络、应用六大子系统的观测工具，再到容器云环境的特殊挑战与自定义工具开发。但如果把这本书的学习比作学医，前十二章教的是解剖学、药理学和器械使用——而本章是临床实习：面对一个真实的、症状模糊的病人，你如何组织你的知识完成一次完整的诊断。工具用法可以在手册里查到，诊断思维却只能在案例中习得。这正是案例研究这一章存在的理由，也是 Brendan Gregg 在原书中把大量真实案例穿插于各章的原因：性能分析本质上是一门经验科学，每一次成功的诊断都是"假设-观测-推理-验证"循环的一次完整执行。

为什么从工具用法到诊断思维之间存在鸿沟？因为真实故障从不按教科书分类。生产环境里没有人会告诉你"这是一个 CPU 调度延迟问题，请使用 runqlat"——你得到的全部信息往往只是"服务变慢了"、"P99 延迟抖动"、"内存一直在涨"这样模糊的症状。从症状到工具选择，中间需要一整套推理框架：首先要建立系统的心智模型（一个请求从网卡进来，经过中断、软中断、协议栈、socket 缓冲、应用线程、系统调用、页缓存或块设备层，最终返回——每一环都可能是瓶颈）；然后要用最廉价的手段快速缩小范围（60 秒检查法：uptime 看负载、dmesg 看内核报错、vmstat 看 CPU/内存/交换、mpstat 看每核分布、pidstat 看进程、iostat 看磁盘、free 看内存、sar 看历史）；最后才轮到 BPF 显微镜对可疑区域做高分辨率观测。这个"先粗后细、先廉价后昂贵"的分层排除过程，是所有高效诊断的共同骨架。

BPF 诊断方法论的核心可以概括为三条原则。第一条：先假设后验证。拿到症状后，基于心智模型列出所有可能的假设（延迟抖动可能是：应用代码慢、锁竞争、CPU 饱和、调度延迟、内存回收、磁盘 I/O 慢、网络重传、依赖服务慢、GC 停顿……），然后为每个假设设计一个最低成本的观测来证实或证伪它。BPF 工具的强大之处在于每个观测的成本都极低——runqlat 跑十秒就能给出调度延迟的完整分布，不需要重启、不需要改代码、不需要审批变更窗口。第二条：分层排除，用 USE 方法组织。对每种资源检查利用率（Utilization）、饱和度（Saturation）、错误（Errors），BPF 把饱和度这个最难的维度变得可测：runqlat 测 CPU 运行队列等待、biolatency 测磁盘 I/O 延迟分布、offcputime 测线程阻塞时间。当所有资源的 USE 指标都正常而应用依然慢时，问题就在应用内部——这时 offcputime 和 profile 的火焰图成为主力。第三条：让数据说话，警惕确认偏误。诊断者最容易犯的错误是先入为主认定某个原因，然后只收集支持它的证据。BPF 输出的直方图、火焰图、事件流是客观数据，要完整解读而不是选择性摘取——直方图的双峰、火焰图里的意外宽塔、事件流里的陌生进程名，往往才是真相所在。

本章选取的六个案例覆盖了生产环境最常见的五大子系统故障模式，选取逻辑是"每个案例代表一类观测视角"。案例一（execsnoop 追踪短生命周期进程）代表事件级观测：有些问题在采样式工具（top、ps）中根本不可见，因为故障主体是瞬态的——每 10 秒 fork 一次的短命进程在两次采样之间来去无踪，只有基于 tracepoint 的事件追踪才能一个不漏地捕获。案例二（runqlat 诊断调度延迟）代表延迟分布观测：CPU 使用率不高不等于 CPU 不缺——在容器 CPU 超卖、quota 限流、NUMA 迁移的场景下，线程在运行队列里等待的时间可以很长，runqlat 的直方图让这种"隐形饱和"无所遁形。案例三（biosnoop 定位磁盘 I/O 瓶颈）代表逐事件归因观测：iostat 只能告诉你磁盘忙，biosnoop 能告诉你每一个 I/O 是谁发的、多大、延迟多少——把"磁盘慢"精确到"哪个进程的哪种 I/O 慢"。案例四（tcpretrans 排查网络重传）代表内核协议栈观测：网络偶发超时是最难复现的故障类型，tcpdump 抓包数据量巨大且难以关联到连接，tcpretrans 直接挂载内核重传函数，每个重传事件带上时间戳、源目的地址、端口和状态序号，让偶发问题变成可统计的事件流。案例五（memleak 追踪内存泄漏）代表采样式栈聚合观测：内存缓慢增长的问题用常规手段只能看到结果看不到原因，memleak 通过采样 malloc/mmap 且未被 free 的分配调用栈，直接指出"哪段代码在泄漏"。案例六（offcputime 分析应用阻塞）代表 off-CPU 观测：CPU 火焰图回答"CPU 时间花在哪"，off-CPU 火焰图回答"线程不在 CPU 上时卡在哪"——锁等待、同步 I/O、网络阻塞，这些吞吐量的真正杀手只有 off-CPU 分析能看见。

六个案例合起来构成一个完整的诊断工具箱：事件追踪（execsnoop）、延迟直方图（runqlat）、逐 I/O 归因（biosnoop）、协议栈事件（tcpretrans）、内存栈采样（memleak）、阻塞分析（offcputime）。每个案例都按照统一的结构展开：现象描述（你实际会看到什么）、工具选择理由（为什么是它而不是别的）、追踪过程（具体命令与输出解读）、根因分析（数据如何指向结论）、解决方案（修复与验证）、经验总结（可复用的模式）。我们强烈建议你不仅阅读这些案例，更要按照 labNotes 中的演练设计亲手复现它们——诊断能力像游泳一样，看是学不会的。

最后要强调的是诊断的"最后一公里"：找到根因只是诊断的一半，另一半是把诊断过程沉淀为组织资产。每个案例的结尾我们都会讨论应该记录什么、如何验证修复有效、如何把一次性的排查变成常态化的监控指标。BPF 工具的另一个巨大优势在这里显现：诊断用的命令本身开销极低，可以直接固化为持续监控——runqlat 的直方图可以每分钟采集一次进时序数据库，execsnoop 可以变成安全审计流。诊断与监控的边界在 BPF 时代变得模糊，这正是现代可观测性工程的方向。

核心概念

• execsnoop
• runqlat
• biosnoop
• tcpretrans
• memleak
• offcputime

要点精析

【案例一的诊断思维：短生命周期进程是采样式工具的盲区】现象回顾：CPU 使用率出现周期性尖峰，但 top 里看不到任何常驻的高 CPU 进程。为什么 top 抓不到？因为 top 默认 3 秒刷新一次，它显示的是采样间隔内的统计——一个存活 50 毫秒的进程在绝大多数采样点上根本不存在，即使碰巧被采样到，其 CPU 占比也被摊薄到不可见。ps 同理。这就是采样式观测的固有盲区：它只能看见"持续存在"的东西。execsnoop 的解法是换一种观测范式——从采样变为事件追踪，挂载在 syscalls:sys_enter_execve tracepoint 上，每一次进程创建都触发一条记录，带时间戳、PID、父 PID、进程名和完整参数。诊断这类问题的关键推理链是：周期性尖峰 → 尖峰周期提示定时任务（cron、systemd timer、监控 agent 的采集周期）→ 用 execsnoop 观察一个完整周期内的所有进程创建 → 找到与尖峰时间对齐的高频短命进程 → 用 ps 查其父进程链定位发起者。本案例的根因是某遗留监控 agent 每 10 秒 fork 十几个子进程执行采集脚本，fork+exec+进程销毁的成本（页表复制、调度、缓存污染）叠加成尖峰。解决方案是改造为常驻守护进程，用线程或事件循环替代反复 fork。经验总结：凡遇"周期性"异常，先想定时器；凡遇"top 看不到"，先想短命进程；execsnoop 是进程创建事件的完整账本，一个都不会漏。

【BPF 工具选择的决策树：从症状到工具的映射】六个案例背后是一张可复用的决策树，值得完整梳理。入口问题一：故障主体是瞬态的还是持续的？瞬态进程用 execsnoop，瞬态连接用 tcplife/tcpretrans，瞬态文件访问用 opensnoop。入口问题二：症状属于哪个资源维度？CPU 维度——使用率高用 profile 看 on-CPU 热点，使用率不高但延迟抖动用 runqlat 看调度等待；内存维度——持续增长用 memleak 找泄漏栈，回收频繁用 cachestat 看页缓存命中，缺页严重用 pagefault 类工具；磁盘维度——整体慢用 biolatency 看延迟分布，要归因到进程用 biosnoop；网络维度——重传用 tcpretrans，连接生命周期用 tcplife，丢包用 trace 挂 skb:kfree_skb。入口问题三：应用慢但资源都正常？先看 on-CPU（profile 火焰图：CPU 时间花在哪个函数），再看 off-CPU（offcputime 火焰图：阻塞在哪个内核栈）——两者合起来才是线程时间的完整账本。这张决策树的每个叶子都对应一个低成本的观测动作，诊断过程就是沿着树快速试探：每个工具跑 10-30 秒，看输出是否异常，异常则深入，正常则排除。这种"广撒网、快排除"的风格只有在工具开销足够低时才可行——这正是 BPF 相对 strace/SystemTap 的方法论级优势。

【案例二的诊断思维：CPU 使用率不高不等于 CPU 不缺】现象回顾：应用 P99 延迟周期性抖动，但监控显示 CPU 使用率只有 40%。这是容器时代最经典的误判场景。使用率是"CPU 在忙"的比例，但它无法区分"线程在 CPU 上执行"和"线程在运行队列里等待被调度"——后者是纯粹的浪费，却不体现在使用率里。runqlat 挂载调度器 tracepoint（sched:sched_wakeup 和 sched:sched_switch），测量每个线程从被唤醒到真正获得 CPU 的等待时间，输出 2 的幂次分桶直方图。健康的系统里绝大多数等待在微秒级（2-6 号桶）；如果直方图出现毫秒级的长尾甚至双峰，说明存在调度饱和。本案例的推理链：P99 抖动 → 抖动幅度（几十毫秒）与调度延迟量级吻合 → runqlat 显示 5% 的唤醒等待超过 20 毫秒 → 检查 cgroup 配置发现 CPU quota 设置过低（limit 2 核但突发并发 8 线程），quota 耗尽后整个 cgroup 被 throttle 到下一个周期 → 根因是 CPU 超卖加 quota 限流。解决方案：调高 quota 或对延迟敏感线程绑核（cpuset），并用 container_throttling 类工具验证 throttle 时间归零。经验总结：容器环境诊断延迟问题，runqlat 必须纳入第一批检查；直方图的双峰形态是 throttle 的指纹——一峰是正常调度，另一峰是被限流后的整周期等待。

【从输出到根因的推理方法：读懂直方图、事件流与火焰图】BPF 工具的三种主要输出形态各有解读要领。直方图（runqlat、biolatency）：先看主峰位置（正常延迟量级），再看长尾（P99/P999 落在哪个桶），最后看形态——单峰偏右是整体慢（资源能力不足），双峰是两种机制混合（如缓存命中与未命中、正常调度与 throttle），指数衰减的长尾是排队论特征（饱和）。平均值几乎无用，分布才是信息所在。事件流（execsnoop、biosnoop、tcpretrans）：先数频率（每秒多少事件），再看主体（哪个进程/连接占多数），然后找异常模式（周期性、突发性、与故障时间的相关性），最后抽样深挖单条事件的字段（biosnoop 的进程名+扇区数、tcpretrans 的状态序号）。事件流的价值在于归因——把系统级指标精确到责任主体。火焰图（profile、offcputime）：x 轴宽度是时间占比（不是调用顺序），找最宽的塔就是找最大的时间消费者；on-CPU 火焰图里宽塔是热点函数，off-CPU 火焰图里宽塔是阻塞点——栈底到栈顶读出一条完整的因果链（谁调用了谁，最终阻塞在哪个内核函数）。三种形态的组合使用是常态：直方图定量（问题多大）、事件流归因（谁造成的）、火焰图定位（代码级根因）。训练自己"看一眼输出就能说出三句话结论"的能力，是从会用工具到精通诊断的分水岭。

【案例三的诊断思维：biosnoop 把"磁盘慢"精确到责任进程】现象回顾：数据库查询变慢，iostat 显示磁盘 util 接近 100%，await 升高。iostat 的局限在于它只有设备视角：你知道磁盘忙，但不知道是谁在制造 I/O、是顺序还是随机、是读还是写。biosnoop 挂载块层 tracepoint（block:block_rq_issue 和 block:block_rq_complete），为每一个块设备 I/O 输出一行：时间戳、进程名、PID、磁盘、扇区、大小、延迟。诊断推理链：数据库变慢与磁盘 await 升高时间吻合 → biosnoop 观察发现除了 mysqld 的正常 I/O 外，还有大量来自 tar/gzip 进程的大块随机读 → 查进程树发现是备份任务在业务高峰期启动 → 备份的顺序大流量读打满磁盘队列，数据库的随机小 I/O 排在后面等待 → 根因是 I/O 资源竞争。解决方案分两层：短期用 ionice 降低备份进程优先级并限速（如 pv -L 或备份工具自带限速），长期用 cgroup v2 的 io.max 给业务进程保底带宽，并评估 I/O 调度器（NVMe 用 none，SATA SSD 用 mq-deadline，机械盘用 bfq 配合 ionice 才有意义）。经验总结：磁盘问题诊断的标准路径是 biolatency 定量（延迟分布多糟）→ biosnoop 归因（谁制造的）→ 按进程聚合的统计确认占比；"后台任务抢占 I/O"是数据库变慢最常见却最容易被忽略的原因，因为备份任务往往在监控盲区里。

【案例四的诊断思维：tcpretrans 让偶发网络问题变成可统计事件】现象回顾：跨服务调用偶发超时，频率低、无规律、难以复现。网络问题的诊断难点在于偶发性：tcpdump 全量抓包数据量巨大，且事后从包里找重传如同大海捞针；netstat -s 的重传计数只有总量，无法关联到具体连接和时间。tcpretrans 挂载内核的 tcp_retransmit_skb 函数（kprobe），每个重传事件输出一行：时间戳、PID、源 IP:端口 → 目的 IP:端口、TCP 状态、序列号。诊断推理链：应用超时时间点与 tcpretrans 记录的重传事件精确对齐（重传超时 RTO 最小 200 毫秒，与应用超时量级吻合）→ 重传集中在特定几台目标机器 → 登录目标机器看 netstat -s 与 /proc/net/softnet_stat，发现 softnet 的 dropped 列在增长 → 进一步用 ethtool -S 查看网卡统计，rx_missed_errors/rx_no_buffer_count 非零且持续增长 → 根因是流量突发时网卡 ring buffer 溢出丢包，触发 TCP 重传。解决方案：ethtool -G 增大 ring buffer（如 4096），配合 RSS 多队列与 irqbalance/RPS 把中断分散到多核避免单核软中断饱和，验证方式是重跑 tcpretrans 观察重传率归零。经验总结：网络偶发超时的排查顺序是 tcpretrans（确认重传与超时的相关性）→ 定位丢包点（本机发送侧、网络中、对端接收侧）→ 对端接收侧丢包看 softnet_stat 和 ethtool -S；重传是结果不是原因，找到丢包发生的位置才是根因。

【案例五的诊断思维：memleak 用采样与栈聚合直接指出泄漏代码】现象回顾：服务内存持续增长，数天后触发 OOM kill，重启后重新开始增长。常规手段的局限：top/ps 只能看到 RSS 在涨，pmap 能看到哪个映射段在涨但看不到是谁分配的，valgrind 能精确追踪但开销 10-50 倍且需要重启应用，生产环境不可用。memleak 的策略是采样加聚合：挂载 malloc/free（或内核的 kmalloc/kfree，用 -k 选项）的 uprobe/kprobe，记录每次分配的大小和调用栈，free 时销账；周期性输出"已分配但未释放"的总量按调用栈聚合排序。为控制开销，它支持采样率参数（-s，如每 N 次分配采一次）和分配大小过滤（-z 只追踪大于某阈值的分配）。诊断推理链：memleak 运行 10 分钟，输出显示某个用户态栈累计未释放 800MB 且线性增长 → 栈顶是应用自己的缓存写入函数 → 代码审查确认该缓存以请求 ID 为键写入但从未设置过期 → 根因是缓存对象无 TTL 无上限，无限累积。解决方案：引入 LRU 淘汰策略与内存上限（如 2GB 硬顶），并用 memleak 复测确认增长曲线变平。经验总结：内存泄漏诊断的关键是"增长率"而非绝对值——先确认泄漏速率（每小时多少 MB）来估算可接受的观测窗口，再让 memleak 跑足够长的时间使泄漏栈与正常分配的栈在聚合量上拉开差距；对分配极频繁的应用务必用采样模式，否则 uprobe 开销会拖垮服务。

【案例六的诊断思维：offcputime 揭示吞吐量的隐形杀手】现象回顾：应用吞吐量上不去，但 CPU 使用率只有 20%，profile 的 on-CPU 火焰图也看不出明显热点。这个组合是 off-CPU 分析的经典适应症：线程的大部分时间不在 CPU 上，而在阻塞——on-CPU 剖析对阻塞时间完全失明。offcputime 挂载 sched:sched_switch，在线程被切换出 CPU 时记录时间戳和内核栈（可选加用户栈），切回时计算 off-CPU 时长并按栈聚合，最终生成 off-CPU 火焰图：宽度代表阻塞总时长。诊断推理链：offcputime 跑 30 秒生成火焰图 → 最宽的塔显示工作线程阻塞在 futex_wait（锁等待），占 off-CPU 时间 45% → 第二宽的塔显示阻塞在 io_schedule 下的同步 read（占 30%）→ 结合代码确认：全局配置对象用一把大互斥锁保护，每次请求都要读它；日志写入是同步的且未缓冲 → 根因是锁竞争加同步 I/O 双重阻塞。解决方案：把大锁改为读写锁或无锁的 RCU 风格快照（配置更新时整体替换指针），日志改为异步批量写入（内存队列加后台刷盘线程），复测 offcputime 确认阻塞占比大幅下降、吞吐量提升 3 倍。经验总结：吞吐量低加 CPU 低的组合，答案几乎一定在 off-CPU 时间里；off-CPU 火焰图的三大常见宽塔——futex（锁）、io_schedule（同步 I/O）、sk_wait_data（网络等待）——分别指向锁优化、异步化、连接与缓冲调优三个方向。

【常见误诊与避免：六个案例教会我们的反面清单】误诊一：把相关当因果。tcpretrans 显示重传与应用超时同时发生，就断定网络是根因——但重传也可能只是应用超时后连接被杀的表现。避免方法：检查时序（重传在前还是超时在前）与量级（重传率是否足以解释超时比例）。误诊二：被直方图的平均值安抚。平均延迟 1 毫秒听起来健康，但 P999 是 200 毫秒时，延迟敏感业务已经受损。避免方法：永远看分布和分位数，runqlat/biolatency 的 -p 选项可以直接输出分位数。误诊三：观测窗口太短。周期性故障（如每 10 分钟的 cron、每小时的对账任务）用 30 秒的观测窗口可能完全错过。避免方法：先用 sar 等历史数据确认故障周期，观测窗口至少覆盖两个完整周期。误诊四：工具本身制造假象。对高频 malloc 的应用全量跑 memleak，uprobe 开销使应用变慢，内存行为随之改变——你观测到的是"被 memleak 拖慢的应用"。避免方法：高频路径必用采样模式，观测前后对比应用吞吐确认扰动可接受。误诊五：单工具定案。只用 runqlat 看到调度延迟就下结论，忽略了延迟可能源自上游的锁竞争导致唤醒风暴。避免方法：关键结论至少用两个独立视角交叉验证（如 runqlat 加 offcputime）。误诊六：修复后不验证。调大 ring buffer 后没有重跑 tcpretrans 确认重传归零，一周后问题以另一种形态复发。避免方法：每个修复都必须有"验证观测"——用诊断时的同一工具确认指标恢复正常。

【诊断记录的规范化：把个人经验变成组织资产】一次完整的 BPF 诊断应该留下结构化的记录，建议模板包含六段。第一段症状：精确描述现象（什么指标、什么量级、什么时间模式），附上原始监控截图或数据导出——"服务变慢"不是症状，"P99 从 80 毫秒周期性升至 400 毫秒，周期约 10 分钟，持续两周"才是。第二段环境：内核版本（uname -r，决定哪些 BPF 工具可用）、发行版、容器运行时、硬件规格、应用版本——BPF 工具行为与内核版本强相关，没有环境信息的记录无法复现。第三段观测过程：按时间顺序列出执行的每条命令、关键输出（截取有信息量的部分）、以及每一步的推理（"看到 X 所以排除了 Y"）——推理链比命令本身更有价值。第四段根因：一句话结论加证据链（哪些数据支持这个结论，排除了哪些替代假设）。第五段修复与验证：改了什么、用什么观测确认有效、指标恢复前后的对比数据。第六段沉淀：这次诊断能否固化为常态监控（如把 runqlat 的 P99 纳入告警）、是否需要补充 runbook、是否暴露了架构问题（如备份与业务争抢 I/O 应该从架构上隔离）。规范记录的复利效应巨大：团队积累五十份这样的案例后，新故障的诊断往往能在历史记录里找到相似模式，平均诊断时间会数量级下降。这也是本书六个案例采用统一结构的深层用意。

【分层排除方法论：从 60 秒检查到 BPF 显微镜的完整路径】把六个案例的经验整合成一条标准诊断流水线。第一层，60 秒检查（成本几乎为零）：uptime 看负载趋势（负载高但 CPU 使用率低提示 I/O 等待或调度问题）、dmesg 看 OOM/网卡丢包/硬件报错、vmstat 1 看 r 列（运行队列长度，持续大于核数即 CPU 饱和）与 wa 列（I/O 等待）、mpstat -P ALL 看是否单核热点（软中断集中）、pidstat 看进程级 CPU、iostat -xz 看磁盘 util 与 await、free 看可用内存与交换、sar -n DEV 看网卡流量与错误。这一层通常能把范围缩小到一两个子系统。第二层，子系统专用 BPF 工具定量（每个 10-30 秒）：CPU 嫌疑跑 runqlat 与 profile，内存嫌疑跑 memleak 与 cachestat，磁盘嫌疑跑 biolatency 与 biosnoop，网络嫌疑跑 tcpretrans 与 tcplife。第三层，深度归因：直方图异常后用事件流工具找责任主体（biosnoop 找进程、tcpretrans 找连接），应用内部问题用 on-CPU 加 off-CPU 火焰图定位到代码栈。第四层，假设验证与修复：基于定位结果提出修复方案，实施后用同一套观测确认指标恢复。整个流水线的精髓是每层都用最小成本换取最大信息量，BPF 工具位于第二三层——它们不是起点而是显微镜，跳过第一层直接上 BPF 是新手最常见的低效模式；但停留在第一层不敢用 BPF 则永远无法深入根因。

代码示例

/* 案例一核心命令：execsnoop 追踪进程创建，带时间戳与父进程 */
/usr/share/bcc/tools/execsnoop -tT
/* 输出示例：
TIME     PCOMM            PID    PPID   RET    ARGS
14:23:01 cron             28451  1102     0    /usr/bin/perl /opt/monitor/collect.pl
14:23:01 perl             28452  28451    0    /bin/sh -c df -h | grep -v tmpfs
14:23:01 sh               28453  28452    0    df -h
14:23:11 cron             28460  1102     0    /usr/bin/perl /opt/monitor/collect.pl
*/

-t 输出时间戳，-T 输出完整时间（含日期），这两个选项对周期性故障至关重要——你需要把进程创建时间与 CPU 尖峰时间对齐。解读这段输出：PPID 为 1102 的 cron 每 10 秒（14:23:01、14:23:11）启动同一个 perl 采集脚本，脚本又派生 sh 和 df 子进程——一次采集产生三四个短命进程。RET 列是 execve 的返回值，0 表示成功，非零可以捕获执行失败（如脚本路径错误）。确认嫌疑后的深挖命令：用 ps -ef 查 PPID 1102 确认是 crond，用 grep -r collect /etc/cron* 或 crontab -l 找到任务定义（注意有些 agent 用内部定时器而非 crontab，此时查 /proc/1102/cmdline 与父进程链）。量化影响可以配合 bpftrace 统计频率：bpftrace -e 'tracepoint:syscalls:sys_enter_execve { @[comm] = count(); } interval:s:60 { print(@); clear(@); }' 每分钟输出各进程名的 exec 次数，周期性尖峰的元凶会以远高于其他进程的频率出现。修复验证：改造为常驻进程后重跑 execsnoop，确认该 perl 脚本不再反复出现，同时用 vmstat 1 观察 CPU 尖峰消失。

/* 案例二核心命令：runqlat 生成调度延迟直方图，10 秒一个区间共 6 个 */
/usr/share/bcc/tools/runqlat 10 6
/* 输出示例（截取一个区间）：
     msecs           : count     distribution
         0 -> 1      : 18432    |****************************************|
         2 -> 3      : 2104     |****                                    |
         4 -> 7      : 315      |*                                       |
         8 -> 15     : 89       |                                        |
        16 -> 31     : 412      |*                                       |
        32 -> 63     : 388      |*                                       |
*/

runqlat 的两个位置参数是区间秒数与区间个数，持续采样便于观察延迟与业务周期的相关性。解读这个直方图：主峰在 0-1 毫秒（18432 次）看似正常，但 16-63 毫秒区间出现了异常的第二个峰（412+388 次）——健康系统的调度延迟应该从主峰单调衰减，双峰形态几乎总是两种机制混合的信号。结合容器环境，16-63 毫秒恰好是 cgroup CPU throttle 的典型量级（quota 周期默认 100 毫秒，被限流的线程要等到下个周期）。验证命令：cat /sys/fs/cgroup/cpu/<容器路径>/cpu.stat 查看 nr_throttled 与 throttled_time 是否持续增长；或用 bpftrace 直接观测限流事件。进一步归因到具体进程：runqlat -p <PID> 只统计目标进程，runqlat -P 按进程分别输出直方图，可以确认哪些进程受害最重。修复验证：调高 cpu.max quota 或绑核后，重跑 runqlat 10 6，确认 16 毫秒以上的桶归零、双峰变单峰。经验值：延迟敏感服务应保证 99.9% 的调度延迟在 1 毫秒内，任何毫秒级长尾都值得追查。

/* 案例三核心命令：biosnoop 逐 I/O 追踪，-Q 包含队列等待时间 */
/usr/share/bcc/tools/biosnoop -Q
/* 输出示例：
TIME(s)     COMM           PID    DISK   T SECTOR     BYTES  QUE(ms)  LAT(ms)
0.000000    mysqld         2145   vdb    R 8842112    16384     0.42     1.21
0.000103    tar            29871  vdb    R 1048576    131072    8.31    45.67
0.000215    tar            29871  vdb    R 1310720    131072   12.44    52.30
0.000318    mysqld         2145   vdb    R 8858496     8192   15.20    48.92
*/

biosnoop 每行是一个块设备 I/O：T 是读（R）写（W），SECTOR 起始扇区，BYTES 大小，QUE 是在 I/O 调度队列里的等待时间，LAT 是从入队到完成的总延迟。-Q 选项让 QUE 列生效，这一列是区分"磁盘本身慢"与"排队慢"的关键。解读这段输出：tar 进程（PID 29871，备份任务）在做大块顺序读（131072 字节即 128KB），mysqld 的小块随机读（8-16KB）QUE 时间从正常的 0.42 毫秒飙升到 15.20 毫秒——数据库的 I/O 排在备份的大 I/O 后面等待，这是典型的 I/O 队列头阻塞。注意 mysqld 的 LAT 也到了 48.92 毫秒，说明受害严重。按进程聚合确认占比：bpftrace 或 biosnoop 输出配合 awk 统计各进程的 I/O 总量与平均延迟。修复命令：ionice -c3 tar ... 把备份降为 idle 优先级（仅对 bfq/cfq 调度器有效），或用 cgroup v2 的 io.max 限制备份进程带宽（echo "253:16 rbps=52428800" 限 50MB/s）；NVMe 设备上 ionice 无效（调度器为 none），必须用 cgroup 限速。验证：重跑 biosnoop 确认 mysqld 的 QUE 回到 1 毫秒以内。

/* 案例四核心命令：tcpretrans 追踪重传，-c 显示拥塞窗口信息 */
/usr/share/bcc/tools/tcpretrans
/* 输出示例：
TIME     PID     IP LADDR:LPORT          T> RADDR:RPORT       STATE
19:02:11 3842    4  10.0.1.5:44312       R> 10.0.2.8:8080     ESTABLISHED
19:02:12 3842    4  10.0.1.5:44312       R> 10.0.2.8:8080     ESTABLISHED
19:02:45 5127    4  10.0.1.5:51840       R> 10.0.3.2:443      ESTABLISHED
*/

tcpretrans 每行是一次 TCP 重传：LADDR:LPORT 是本端地址端口，RADDR:RPORT 是对端，STATE 是重传发生时的 TCP 状态，R> 标记表示这是重传（Fast Retransmit 会显示为 F>，开启 -l 选项还能看到尾丢包探测 TLP）。解读方法分三步。第一步看频率与分布：重传是集中在少数连接（特定对端或特定服务）还是普遍存在？普遍存在提示本机或网络基础设施问题，集中存在提示对端或路径问题。第二步对齐时间：把重传时间戳与应用超时日志对齐——RTO 重传意味着至少 200 毫秒的延迟惩罚，与应用 P99 抖动的量级和时刻吻合即可建立因果。第三步定位丢包点：重传说明有包丢了，丢在哪？本机发送侧看 netstat -s 的发送错误与 qdisc 丢包（tc -s qdisc show），网络中看路径 MTU 与中间设备，对端接收侧登录对端查 cat /proc/net/softnet_stat（第二列 dropped 非零即软中断处理不过来）与 ethtool -S eth0 | grep -E "missed|no_buffer|drop"（ring buffer 溢出）。本案例即在对端发现 rx_missed_errors 持续增长，修复为 ethtool -G eth0 rx 4096 增大 ring buffer，并把网卡多队列中断用 set_irq_affinity 分散到多个 CPU。验证：修复后重跑 tcpretrans 十分钟，重传事件从每分钟数十次降为零。

/* 案例五核心命令：memleak 采样用户态分配，每 5 秒输出一次 top 10 栈 */
/usr/share/bcc/tools/memleak -p 3842 -s 10 -z 1024 -o -T 5
/* 输出示例：
     812345678 bytes in 12453 allocations from stack
             malloc+0x28 [libc-2.31.so]
             CacheManager::put+0x9c [libappcache.so]
             RequestHandler::process+0x214 [appserver]
             main+0x1a2c [appserver]
*/

参数解读：-p 限定目标进程（生产环境必加，否则追踪全系统开销失控），-s 10 采样模式每 10 次分配采 1 次（高频 malloc 应用的救命参数），-z 1024 只追踪大于 1KB 的分配（过滤海量小分配，聚焦可能泄漏的大对象），-o 忽略分配器内部帧让栈更干净，-T 5 每 5 秒输出一次。输出解读：这段栈显示累计 812MB 未释放内存来自 CacheManager::put 路径——关键是跨多个输出周期观察：如果同一个栈的累计值随时间线性增长而其他栈稳定，它就是泄漏点；如果所有栈都在涨，可能是应用正常处理量上升或 memleak 的 free 追踪不完整（如自定义分配器绕过了 malloc）。本案例中该栈每小时增长约 400MB，与 RSS 增长速率吻合，证据链闭合。注意事项：memleak 基于 uprobe 挂 malloc/free，对静态链接或自定义分配器（如 Go 的运行时、jemalloc 直接调用）需要相应调整（Go 程序用 -a 显示所有分配或用其他手段）；追踪内核内存用 -k 挂 kmalloc/kfree。修复验证：上线 LRU 淘汰后重跑相同命令 30 分钟，确认该栈的累计值稳定在缓存上限附近不再增长。

/* 案例六核心命令序列：offcputime 采集 30 秒并生成 off-CPU 火焰图 */
/usr/share/bcc/tools/offcputime -df -p 3842 30 > out.stacks
/* 输出为折叠栈格式：进程名;用户栈;内核栈 阻塞微秒数 */
stackcount-uncollapsed.pl out.stacks > out.folded   /* 如需转换 */
flamegraph.pl --color=io --title="Off-CPU Time" --countname=us out.folded > offcpu.svg
/* 火焰图中的关键宽塔（文字示意）：
appserver;process_request;CacheManager::get;pthread_mutex_lock;futex_wait  45%
appserver;write_log;__write_nocancel;io_schedule;wait_on_page_bit         30%
appserver;epoll_wait;schedule_hrtimeout_range                              15%
*/

命令解读：-d 输出折叠栈格式（火焰图工具直接可用），-f 包含内核栈与用户栈的完整折叠，-p 限定进程，30 是采集秒数。offcputime 的原理是挂载 sched:sched_switch：线程被切出时记录时间戳与栈，切回时把 off-CPU 时长累加到该栈上——所以火焰图宽度是阻塞总时长而非采样次数。解读这段火焰图：最宽的塔（45%）从 process_request 经 pthread_mutex_lock 到内核的 futex_wait——工作线程近一半的阻塞时间在等互斥锁，且调用路径指向 CacheManager::get，与案例五的锁使用模式互相印证；第二宽塔（30%）是同步写日志阻塞在 io_schedule 的页回写上；epoll_wait 的 15% 是正常的事件等待（不算问题，可视为线程空闲）。修复优先级由此确定：先解决占比最大的锁竞争（读写锁或 RCU 快照替换），再异步化日志。注意事项：offcputime 对高频切换的进程开销较大（每次切换触发一次 BPF 程序加抓栈），生产环境建议限定 -p 并控制时长；只统计超过阈值的阻塞可加 -m 参数（如 -m 1000 忽略小于 1 毫秒的切换）过滤噪声。验证：优化后重跑相同命令，确认 futex_wait 塔占比降到 10% 以下，同时应用吞吐量指标上升。

实验笔记

本实验设计一个完整的"BPF 诊断实战演练"：在可控环境中注入六类模拟故障，要求你像值班 SRE 一样完成"症状 → 工具选择 → 追踪 → 根因 → 修复 → 验证"的全流程。预计耗时 5-6 小时。环境准备：一台内核 4.9+ 的 Linux 虚拟机（推荐 5.8+，2 核 4GB 即可），安装 bcc-tools、bpftrace、sysstat、stress-ng、FlameGraph 工具集（git clone https://github.com/brendangregg/FlameGraph）；准备一个可注入故障的演示应用（可用简单的 Python/Go HTTP 服务，或直接用 stress-ng 模拟资源压力）。演练规则：每个场景先只看"症状卡片"（模拟监控告警），自行决定用什么工具诊断，写出诊断记录（按 keyPoints 中的六段模板），最后对照"参考答案"验证。

【场景一：幽灵进程】故障注入：写一个脚本模拟恶意/遗留任务——while true; do for i in 1 2 3 4 5; do (echo "scale=100000; 4*a(1)" | bc -l > /dev/null &) ; done; sleep 10; done 后台运行（每 10 秒启动 5 个短命 bc 计算进程）。症状卡片："监控显示 CPU 每 10 秒出现一次 2 秒的尖峰，top 刷新时看不到高 CPU 进程。"诊断要求：用 execsnoop 捕获短命进程，通过 PPID 追溯发起者，用 bpftrace 统计 exec 频率量化。参考答案要点：execsnoop -tT 输出中每 10 秒出现一批 bc 进程，父进程为 sh 脚本；修复即 kill 该脚本，验证尖峰消失。

【场景二：隐形限流】故障注入：用 systemd-run 启动一个 CPU 密集任务并限制配额——systemd-run --scope -p CPUQuota=20% stress-ng --cpu 4 --timeout 120s（4 个线程争抢 0.2 核的配额，必然被大量 throttle）。症状卡片："任务吞吐远低于预期，但系统整体 CPU 使用率不到 30%。"诊断要求：用 runqlat -P 观察各进程调度延迟直方图，识别毫秒级长尾；查 cgroup 的 cpu.stat 确认 nr_throttled 增长。参考答案要点：stress-ng 进程的 runqlat 直方图出现 10-100 毫秒的第二峰（quota 周期 100 毫秒的 throttle 特征）；修复即调高 CPUQuota，验证双峰变单峰。

【场景三：I/O 抢占】故障注入：一个终端跑 stress-ng --hdd 2 --hdd-bytes 1G --timeout 180s 制造持续磁盘压力，同时用 dd if=/dev/zero of=/tmp/test bs=4k count=10000 oflag=sync 模拟"数据库"的小块同步写。症状卡片："dd 的写入速率从平时的 50MB/s 掉到 3MB/s。"诊断要求：先用 iostat -xz 1 确认磁盘饱和，再用 biosnoop 观察 dd 的 I/O 的 QUE 与 LAT 列，识别排队等待是延迟主因；用 biosnoop 输出统计 stress-ng 与 dd 各自的 I/O 占比。参考答案要点：dd 的每个 4K 写 QUE 时间达数十毫秒，stress-ng 占 I/O 总量 90% 以上；修复即 ionice -c3 或 cgroup io.max 限制 stress-ng，验证 dd 速率恢复。

【场景四：锁竞争与阻塞】故障注入：写一个多线程 Python 程序，8 个线程争抢一把全局锁，每次持锁 sleep 0.01 模拟慢临界区，主逻辑同时做同步文件写。症状卡片："程序 CPU 使用率 15%，吞吐量极低。"诊断要求：先跑 profile 30 确认 on-CPU 无热点，再跑 offcputime -df -p <PID> 30 生成 off-CPU 火焰图，识别 futex_wait 宽塔及其用户态调用路径。参考答案要点：火焰图中 pthread_mutex_lock → futex_wait 占 off-CPU 时间 60% 以上，栈指向持锁 sleep 的函数；修复即缩小临界区（把 sleep 移出锁外），验证火焰图中锁塔占比下降、吞吐上升。

【场景五：内存泄漏】故障注入：python3 -c "import time; cache=[];

while True:

cache.append(b'x'*102400)

time.sleep(0.1)" 后台运行（每 100 毫秒泄漏 100KB，约每小时 3.5GB）。症状卡片："进程 RSS 每小时增长约 3.5GB，无上限。"诊断要求：先用 pidstat -r -p <PID> 5 确认增长速率，再用 memleak -p <PID> -T 10 观察哪个栈的累计未释放量线性增长。参考答案要点：memleak 输出中 list.append 路径的栈累计值每周期稳定增加约 1MB，与 RSS 增速吻合；对 Python 这类带自己分配器的语言，可讨论 memleak 的局限与 tracemalloc 的互补。

【场景六：网络重传（可选，需两台虚拟机或网络命名空间）】故障注入：用 tc netem 在发送侧注入丢包——tc qdisc add dev eth0 root netem loss 1%。症状卡片："跨机调用 P99 从 20 毫秒升至 300 毫秒。"诊断要求：跑 tcpretrans 观察重传频率与连接分布，用 ping 与 netstat -s 交叉验证丢包存在，检查 tc qdisc show 发现 netem。参考答案要点：tcpretrans 每秒出现与 1% 丢包率匹配的重传事件；修复即 tc qdisc del dev eth0 root，验证重传归零。

【演练交付物】六份诊断记录（六段模板格式）、每场景的关键工具输出截取、off-CPU 火焰图 SVG 文件、以及一份总结：绘制你自己的"症状到工具"决策树并与 keyPoints 中的版本对比。完成标准：每个场景在不看参考答案的前提下独立选对主力工具并定位到注入的故障点。若某场景卡住超过 30 分钟，允许查看参考答案的第一步提示，但需在记录中注明。这套演练每年重做一次，是保持诊断手感的有效方式。

延伸阅读

• Brendan Gregg, "BPF Performance Tools" 第 1 章与附录 A——原书的案例散见于各章（Netflix 的调度延迟排查、Facebook 的内存诊断等），附录 A 的 60 秒检查法与 USE 方法是本章方法论的原始出处，配合本章六个案例阅读效果最佳。
• Brendan Gregg 的博客 (brendangregg.com/blog) 的 Case Study 系列——包括著名的 "Linux Load Averages" 与多起 Netflix 生产故障复盘，每篇都是完整的"症状-观测-推理-根因"叙事，是诊断思维的最佳范文，文风与本章案例一脉相承。
• Netflix Tech Blog 的性能工程板块——BPF 工具在 Netflix 生产环境的规模化应用报告，包括持续剖析（continuous profiling）体系与异常检测实践，展示诊断如何从"救火"演化为"常态化观测"。
• Julia Evans 的 "strace 与 BPF 工具" 系列博文与 zine 小册子——用极简的图示讲解 tcpdump、strace、perf 与 BCC 工具的适用场景，她的 "Bite Size" 系列对建立工具选择的直觉特别有帮助，适合本章演练前快速热身。
• 《Systems Performance: Enterprise and the Cloud》(Brendan Gregg, 第 2 版)——方法论的完整体系：USE 方法、工作负载刻画、各子系统的性能模型与工具矩阵，第 3 章的方法论与本章的分层排除路径互为表里，是诊断思维的系统化教材。
• bcc 仓库的 tools 目录与每个工具的 example.txt——100 多个工具的官方示例输出与用法说明，遇到不熟悉的工具先读它的 example.txt，其中的真实输出样例能帮你预判"正常长什么样"，这是解读异常的前提。
• Facebook/Meta 工程博客的 BPF 实践文章（如 "Tracking down memory leaks with BPF"）——大规模生产环境中 memleak、oomkill 等工具的应用案例，与本章案例五形成对照，展示内存诊断在百万台机器规模下的工程化形态。
• LWN.net 的 BPF 专题与 Kernel Recipes 会议视频——内核调度、网络栈、块层的演进直接影响诊断工具的解读（如 cgroup v2 的 throttle 行为、多队列网卡的 RSS），保持对内核变化的跟踪能让你的诊断知识不过期。