一个 Java 微服务组件迁到新的容器平台后，请求延时从虚拟机上的 3–4 秒降到约 1 秒。表面上像是“容器天然快 3–4 倍”，但这只是相关性。调查要区分容器机制、CPU 型号、缓存、负载分配、邻居竞争和调度等因素，并说明收益是否能在正式部署后持续。

案例的价值不在记住一组命令，而在观察专家如何从宽到窄：先同步比较两个环境，用 60 秒检查和 USE 找资源，再看配置、PMC、软件事件和跟踪，最终把多个指标连成相互支持的解释。

1. 同时、同流量的 A/B 对比极其宝贵。 它减少时段、业务组合和趋势变化造成的混淆。
2. 第一层证据是 CPU 饱和差异。 虚拟机 48 个逻辑 CPU、平均负载约 85、CPU 使用率约 98%；容器主机 64 个逻辑 CPU、使用率约 22%，大部分时间空闲。
3. PMC 揭示每个 CPU 周期的效率差异。 案例中 IPC 约为 0.57 对 1.52，LLC 命中率约为 30% 对 90%。
4. 软件事件和 BPF 解释了缓存为何难以预热。 虚拟机每秒约 200 万次上下文切换，目标线程 on-CPU 片段常小于 10 微秒；容器一侧约千次切换，片段常为 2–4 毫秒。
5. 收益不是“容器”单因素。 测试容器几乎没有邻居，拥有更多 CPU 余量和缓存；正式多租户后优势可能下降。

请求时间可以粗分为：

~~~text

总延时

= 等待获得 CPU 的时间

+ 真正在 CPU 上执行的时间

+ I/O、锁与其他等待

~~~

本案例的证据链为：

~~~text

延时差异

→ uptime/mpstat：虚拟机 CPU 饱和

→ vmstat/iostat/sar：运行队列高，磁盘和网络不是主因

→ CPU 配置：核心数、频率、LLC 大小不同

→ PMC：低 IPC + 低 LLC 命中

→ perf 软件事件：上下文切换率极高

→ cpudist：on-CPU 片段极短且多为非自愿切换

→ 结论：排队、竞争和缓存扰动共同造成差异

~~~

关键指标不是孤立阈值，而是两边在同负载下的对照：逻辑 CPU 数、平均负载与运行队列、%idle/%usr/%sys、IPC、LLC 命中、context switches/s、on-CPU 持续时间分布和应用请求延时。

比较还必须校准工作量分母。容器只运行应用的一个组件，而虚拟机承载更完整的工作负载；即使请求率相近，指令与数据工作集也可能不同。每项系统指标最好除以成功请求数或业务操作数，并同时保存请求类型、错误率和 GC 等应用数据，避免把“做得更少”误解为“做得更快”。

1. 与服务团队核对问题、组件边界、流量比例和成功率，确认比较的是同一种请求。
2. 同时登录两边，重复执行相同的短时只读命令，观察趋势而非单点。
3. 用 uptime、mpstat、vmstat、iostat、sar 执行 60 秒检查，再按 USE 标记利用率、饱和与错误。
4. 读取 CPU 数量、型号、频率、超线程和缓存配置，列出所有环境差异。
5. 用 PMC 比较 cycles、instructions、IPC、LLC 与分支行为；只在同类工作负载下解释。
6. 用 perf 统计上下文切换，用 BPF 工具查看 on-CPU/run-queue 分布，检验“调度扰动缓存”的假设。
7. 写出替代解释与适用边界，并通过增加邻居、等量负载或同实例类型的对照实验继续验证。

以下为只读观测或短时计数；将 <code>PID</code> 替换为目标进程。PMC 是否可用取决于云实例、宿主机和权限。

~~~bash

uptime

mpstat 10

vmstat 1 10

iostat -xz 1 10

sar -n DEV 1 10

lscpu

# 每秒显示目标进程上下文切换计数；Ctrl+C 结束

perf stat -e context-switches -p PID -I 1000

# BCC 工具：10 秒后输出一次目标进程 on-CPU 分布

cpudist -p PID 10 1

~~~

案例还使用了特定 PMC 工具。若本机没有同样工具，可从 <code>perf stat -e cycles,instructions -p PID</code> 开始；不同处理器的 LLC 事件和映射不可直接照搬，必须先用 perf list 核对。

平均负载高于 CPU 数量只是一条线索；Linux 平均负载还包含不可中断任务，所以要用 vmstat 的运行队列、mpstat 使用率和 I/O 指标确认。本案例中磁盘与网络活动很少，运行队列和 CPU 使用率共同指向 CPU 饱和。

低 IPC 与低 LLC 命中相互支持，但仍不能单独证明因果。上下文切换率和 on-CPU 分布补上了机制：线程频繁被非自愿切走，既在队列中等待，也很难让当前代码/数据保持热缓存。最终解释由多个独立观测源支持，而不是由单个相关指标决定。

估算“平均负载 85、48 CPU”可提示可运行需求显著超过容量，但书中的速度推导只用于解释当时量级，不能当成普遍公式。正式结论应以请求延时和受控实验复验。

下一轮最有价值的实验是一次只改变一个因素：给容器增加受控邻居，或让两边使用同实例类型和相同组件；再分别固定请求率、比较延时和 PMC。如果增加竞争后容器的切换率升高、LLC 命中下降且延时同步恶化，因果链会更强。若没有变化，就应回到处理器差异、运行时配置或代码路径寻找替代解释。

• 把“运行在容器里”当作唯一变量，忽略宿主机空闲、邻居、CPU 型号和负载分配。
• 两边在不同时间或处理不同请求，却直接比较系统指标。
• 看到高平均负载就断言 CPU 忙，未排除不可中断 I/O。
• 只看总 CPU 利用率，忽略运行队列、超线程竞争、IPC 和 on-CPU 片段。
• 把 30%/90% LLC 命中或 200 万次切换当作所有系统的告警阈值。
• 发现一条符合预期的指标就停止，没有用其他工具或实验验证机制。

1. 为什么该案例适合做同时 A/B 比较？
2. 哪组指标共同证明虚拟机侧主要是 CPU 饱和？
3. IPC 与 LLC 命中率分别补充了什么信息？
4. on-CPU 片段从毫秒降到微秒，为什么可能伤害缓存效率？
5. 为什么不能把 3–4 倍收益归功于容器本身？

检查要点：同流量同时间；负载/运行队列、CPU 使用与低 I/O；周期效率和缓存行为；频繁切换阻断预热；宿主机负载、邻居、配置等混杂因素不同。

高质量性能调查把现象变成可检验假设，再用不同层次证据收敛：服务指标说明影响，USE 找资源，配置说明边界，PMC 解释周期，软件事件和 BPF 揭示调度路径。结论还必须写明适用范围，并设计下一轮实验，而不是给某项技术贴上“天然更快”的标签。