《性能之巅》论证链与证据等级

Gregg 的主张不全在同一个证据强度上。有些靠工程逻辑就能站住，有些靠大量案例支撑，有些高度依赖具体环境。读的时候需要区分。

工程逻辑自洽：可以直接当原则用

USE 方法的防遗漏逻辑

对每种资源检查利用率、饱和度、错误——框架的有效性来自完备遍历，和具体技术栈无关。只要系统涉及多种资源，逐项排查就比随机猜测更可靠。逻辑在排列组合层面就成立，不需要实验验证。

证据类型：方法论推理 + 结构完备性 限制：USE 假设你能列出完整资源清单。遗漏一种资源（比如总线、互联），USE 也会漏掉。

延迟分解的分析价值

把时间拆成 on-CPU 和 off-CPU，然后分别追因。有效性基于一个物理事实：线程在任意时刻要么在 CPU 上执行，要么不在。二者穷尽了所有可能。

证据类型：逻辑穷尽 限制：需要内核级工具支持。用户态指标做不到完整的 off-CPU 归因。

证据成本递进原则

先用计数器，再用 profile，最后用 trace。依据是观测成本递增：计数器几乎免费，profile 有采样开销，trace 有运行时开销。在信息不对称的排障场景下，低成本优先是经济学基本原则。

证据类型：成本收益推理 限制：某些只能重现一次的问题，可能需要跳过低成本层直接上 trace。

大量案例支撑：高置信但非绝对

「先定义问题再选工具」的优先级

Gregg 在多个章节用案例示范：先跑工具后定义问题，误判率显著高于反过来做。证据来自大量工程案例归纳。几乎每个做过排障的工程师都能举出反面例子。

证据类型：案例归纳 + 工程经验 置信度：高 限制：极度紧急的场景（生产事故、SLA 即将违约）下，有时需要先跑工具边看边定义。

「资源利用率正常不等于没有性能问题」

off-CPU 等待、锁竞争、调度延迟、下游依赖——这些瓶颈类型不反映在资源利用率上。Gregg 用了大量案例说明这一点。这也是性能工程领域的广泛共识。

证据类型：案例集合 + 分析逻辑 置信度：高 限制：判断「利用率正常是否是正常的」需要 baseline。没有 baseline，「正常」本身就是主观判断。

火焰图的覆盖边界

on-CPU 火焰图只展示 CPU 采样分布。off-CPU 问题在标准火焰图里看不见。Gregg 反复提醒这一点，并推动了 off-CPU 火焰图的开发。火焰图的采样机制决定了它的覆盖范围。

证据类型：工具设计逻辑 + 实际案例 置信度：高 限制：随着工具演进（off-CPU flame graph、differential flame graph），这条局限正在被部分弥补。

依赖特定环境：需要本地验证

云环境下的边界证据方法

实例间对比、AZ 对比、steal time、cgroup 配额——Gregg 提出这些作为可见性受限时的替代证据。逻辑上成立，但有效性高度依赖具体云平台的指标暴露程度。

证据类型：方法论推理 + 有限环境验证 置信度：中等 AWS、GCP、Azure 上可用的边界证据不完全一样。

BPF 工具的生产安全性

Gregg 推荐在生产环境使用 BPF 做动态观测。BPF 的验证器确实比传统内核模块安全得多，但「生产可用」的判断受内核版本、BPF 运行时和安全策略影响。

证据类型：工具设计原理 + 有限生产验证 置信度：中等 内核 5.x+ 上的 BPF 生态已经成熟，但老内核和非标准环境需要额外验证。

特定工具的输出解读规则

perf stat 的 IPC 阈值、iostat 的 await 解读、网络重传率的告警阈值——这类具体数值的适用性取决于硬件代际、工作负载类型和内核版本。

证据类型：经验值 + 有限环境统计 置信度：低到中等 这些数值是有用的起点，但不能跨环境直接套用。需要在自己的系统上建立 baseline。

整体判断

Gregg 方法体系的核心骨架（USE、延迟分解、证据成本递进）在工程逻辑层面自洽，不依赖特定环境。这些可以直接当原则用。

案例层面的判断（先定义问题、利用率不等于瓶颈、工具输出不等于根因）有大量实践支撑，置信度高，但在极端场景下可能需要灵活处理。

工具和环境相关的判断（云上边界证据、BPF 安全性、具体阈值）需要在自己的环境里验证。不要直接搬。