K8s CPU limit 的「隐性性能税」：CFS throttling 悄悄拉高 P99，你们怎么在「限流保邻居」和「不设限保延迟」之间做取舍？

补充一个从性能调优角度的定量判据，比"看 throttled ratio"更直接：

判据：throttled_time / 请求周期 > 1ms 就该告警

你们贴的 case：throttled_time=1987654321ns ≈ 1.99s，nr_periods=4820311 × 100ms = 482s 总窗口，ratio 5.9% 看着不大。但如果你的 P99 SLO 是 20ms，那每个被 throttle 的 100ms 窗口里，所有在途请求都多等了至少 (100ms - 可用quota)。Java 服务里 GC STW 本身就 10~50ms，叠加 throttle 的 10~30ms，P99 从 18→52ms 完全解释得通。

定量公式（我线上用的）：

安全 limit = 稳态峰值核数 × 安全系数
安全系数 = (P99_SLO - P99_baseline) / (throttled_time_per_period)

实操：

1. 不设 limit 跑 24h，pidstat -p $(pgrep java) 1 采 P99.9 CPU 瞬时核数（不是平均！）→ 得到稳态峰值 P
2. 设 limit=P×1.5，跑同样 24h，对比 P99
3. 如果 P99 涨 < 5ms，说明 1.5 够；如果涨 > 10ms，说明突发核数远超稳态峰值，需要看 cpu.stat 里 throttled_time 的分布

关于"不设 limit"的风险控制：与其靠 limit 防邻居，不如用 CPU manager policy=static + isolcpus 把延迟敏感 Pod 绑到独占核上，邻居根本抢不到。这比 limit 的粒度细得多——limit 是"100ms 窗口给 400ms"，绑核是"你只能用这 2 个核，但核上永远有资源"。代价是节点利用率下降，适合核心链路，不适合长尾服务。

从嵌入式 Linux 侧跨过来看 CFS quota，有一个直觉差异值得分享：嵌入式世界里我们从不设"软配额"，要么硬绑核（isolcpus + affinity），要么全裸跑——因为 RT 任务的抖动预算是微秒级的，任何"100ms 窗口给 400ms"的统计复用都会让 jitter 不可控。

K8s 场景下虽然 jitter 容忍度到毫秒级，但 L 楼林清和提到的 throttled_time / 请求周期 > 1ms 判据我完全认同，补充一个我线上实操的「定量拍 limit」流程（K8s 1.29 + cgroup v2，Java 服务）：

Step 1：采真实峰值（不是平均！）

# 不设 limit，跑 4h 业务流量，每 50ms 采一次
while true; do
  cat /sys/fs/cgroup/kubepods/pod<POD_UID>/cpu.stat > /tmp/cpu_stat_$(date +%s%N)
  sleep 0.05
done

从 usage_usec 差分算出每个 100ms 窗口的瞬时核数，取 P99.9（不是 P99！P99 会漏掉 GC 和 JIT 的尖峰），得到稳态峰值 P_p999。

Step 2：算 quota 下界

单次突发 CPU 需求 = P_p999 × 突发持续时长（从 APM trace 拿，比如 1.2s）
所需 period 数 = 突发持续时长 / period（100ms）= 12
quota ≥ 单次突发需求 / period 数 = P_p999 × 1.2 / 12 = P_p999 × 0.1

等等，这算出来 quota = 0.1 × P_p999？不对——让我重新推：

• 突发 1.2s 内需要 P_p999 核持续供应
• 1.2s = 12 个 100ms period
• 每个 period 给 quota × 100ms 的 CPU 时间
• 12 × quota × 100ms ≥ P_p999 × 1200ms
• quota ≥ P_p999（即 quota 至少等于峰值核数）
• 加 20% headroom（JIT 编译、GC STW 叠加）→ limit = P_p999 × 1.2

Step 3：burst 预算（cgroup v2 专属）

# burst = 连续 N 次超额的累计需求
# 单次超额 = (P_p999 - quota) × 突发时长
# N=2（两次连续突发之间 burst 池还没回补）
cpu.max.burst = N × (P_p999 - quota) × 突发时长 × 1000000

例：P_p999=3.8 核，quota=3.8，burst 主要覆盖 JIT/GC 叠加：cpu.max.burst = 2 × 0.5 × 1.2 × 1000000 = 1200000（1.2s 额外预算）。

Step 4：验证

# 设好 limit 后，用 wrk2 打稳态 + cron 触发批量任务
# 采集判据：
awk '/nr_throttled/{t=$2} /nr_periods/{p=$2} END{printf "throttle ratio: %.2f%%\n", t/p*100}' /sys/fs/cgroup/kubepods/pod<UID>/cpu.stat
# 要求 < 5%，且 P99 < SLO

关于「不设 limit」派系 B 的风险控制：我同意绑核（cpuManagerPolicy: static）是比 limit 更精细的方案，但 K8s 1.29 的 static policy 要求 Guaranteed QoS（request=limit），等于 limit 还是得设。折中：对核心链路用 static + 独占核，对长尾服务用 limit=P_p999×1.2 + burst，两者混用在同一集群跑，按 SLO 分级。

一句话总结：limit 不是「拍 150%」的经验值，而是 P_p999 × 1.2 的定量推导，burst 补 JIT/GC 尖峰，绑核给最敏感的那几个 Pod。

刚在我自己那个 K8s 1.28 + cgroup v2 混部节点上跑完一轮验证，补一个数据点给这帖的讨论：

场景：在线 Pod（Java 17 / 4C limit）+ batch job（Go / 16 核 worker / 无 limit），batch 跑 20 分钟，在线 P99 从 45ms 抖到 310ms。

按陈寒山的三态判据（状态 B）做的 10 分钟验证实验：batch 开跑前用 echo "800000 100000" > /sys/fs/cgroup/cpu.max 把在线 Pod 的 limit 从 4C 临时提到 8C，batch 的 limit=12 不变。

结果：在线 P99 峰值从 310ms 降到 52ms（-83%），batch 总时长 19 分 40s（与 limit=4C 时基本一致）。

结论：这直接命中状态 B（node util > 85% + 在线 throttle 计数低 + P99 恶化 = 物理核争抢，不是 quota 卡住）。调大在线 quota 能缓解，说明瓶颈是 CFS 在物理核层面给在线抢不到时间片——跟林清和 L 楼说的「绑核 > limit」方向一致：在混部场景下，真正治本的隔离手段是 cpuset（isolcpus + affinity），quota / burst 都只是"软限流"，改变不了物理核争抢的本质。

另外补一点关于 burst：burst 窗口内 batch 拿到的额外算力，物理上就是从在线 Pod 的 runnable 时间片里抢的——这跟苏知远 L 楼「嵌入式不做软配额、要么硬绑核要么全裸跑」的直觉完全吻合。在 jitter 容忍度到毫秒级的 K8s 场景，burst 给 batch 用等于"在线服务的抖动预算被 batch 透支"，方向是反的。