Burstable Pod（request=2, limit=4）上 GOMAXPROCS 该对齐 request 还是 limit？CFS period 边界的"假并行"到底让 Go 吞吐损失多少？

背景

• K8s 1.28.9 / containerd 1.7.13 / cgroup v2 / 内核 5.15.0-91，共享节点 16C64G。
• Go 1.22 无状态订单查询服务（HTTP + gRPC 混合），Pod spec cpu.request=2, cpu.limit=4（Burstable QoS，成本原因没给独占）。
• GOMAXPROCS=4（默认对齐 limit）。
• 同节点还有 3 个 Java batch Pod（cpu.limit=4 each），白天跑 ETL，夜间跑批。
• 服务 P99 预算 50ms，常态 25–35ms，QPS 峰值 ~1200。

现象

1. batch 不跑时：P99 稳定 28ms，cpu.stat 的 nr_throttled 几乎不涨，一切正常。
2. batch 跑起来后：P99 抖到 200–500ms，持续 5–15 分钟。cpu.stat 显示 nr_throttled 增量明显，throttled_time / period_time 约 12–28%。
3. 更诡异的一点：即使 nr_throttled=0 的 100ms 周期里（CFS 没切），P99 也比空闲时高 30–50%。我怀疑是 GOMAXPROCS=4 让 Go 调度器认为有 4 个 P 可用，但 CFS 实际只给了 ~2.5 核的有效窗口，goroutine 在 P 上排队——Go 侧看到的是"4 个 worker 全忙"，内核侧是"这个 cgroup 只分到 2.5 核的时间片"，两者之间的 mismatch 造成了"假并行"。
4. GODEBUG=schedtrace=1 输出显示 goroutine 调度延迟（syswait / runnable）在 batch 期间翻了 3–5 倍，但 GC pause 正常（<15ms），排除了 GC 因素。

已尝试的排查与结果

• GOMAXPROCS=2（对齐 request）：P99 抖动幅度从 200–500ms 缩到 80–150ms（改善），但峰值 QPS 从 1200 掉到 ~900（吞吐损失 ~25%），因为 burst 能力被砍掉了。成本上省了 0（request 不变），但业务侧不接受 QPS 下降。
• GOMAXPROCS=4 + cpu.cfs_burst_us=200000：比裸 4 好（P99 峰值从 500ms 降到 ~300ms），但 CFS period 边界的"锯齿"仍在——每 100ms 的 quota 耗尽后，Go 的 4 个 OS 线程同时被冻结，timer 驱动的 time.Ticker 回调全部堆积到下一个 period 释放时集中执行，造成 burst 式延迟尖刺。
• 迁到独占节点（CPU Manager static, 4 核独占）：P99 稳定 30ms，问题彻底消失。但节点利用率从 ~75% 掉到 ~38%，多花了一台机器的成本，对 1200 QPS 的订单服务来说性价比太低。
• 试了 GODEBUG=asyncpreempt=0（禁用异步抢占）：P99 没有改善，反而 GC 变差，已回滚。

期望得到的答案形态

1. 有没有人量化过 GOMAXPROCS=N 在 cpu.max=M（N=M）下，CFS period 边界对 Go 吞吐 / P99 的具体影响？我需要一个"period 边界冻结 → goroutine 堆积 → 集中释放"的延迟分布数据（最好有 schedtrace 或 pprof 的 goroutine 调度延迟直方图）。
2. Burstable Pod 上 GOMAXPROCS 的最佳实践：对齐 request（保守，少抖动少吞吐）？对齐 limit（激进，多吞吐多抖动）？还是动态调（比如通过 Go runtime 的 runtime.SetMaxProcs 根据 cpu.stat 的 throttle 比率自动降级）？
3. Go runtime 有没有 mechanism 能感知 CFS throttle？我目前只能从容器外读 /sys/fs/cgroup/.../cpu.stat，Go 进程内部看不到。有没有人尝试过在 Go 侧做一个 sidecar 或 in-process 的 throttle 感知 → 动态调 GOMAXPROCS 的方案？
4. 有没有比 CPU Manager static 更轻量的"半独占"方案？比如 K8s 的 ExtendedResource + 自定义 scheduler 给关键服务预留 2 核 + 保留 2 核的 burst 能力？或者 cgroup v2 的 cpu.weight 配合 cpu.max 的组合？

引用

• id=1496 的 cpu.cfs_burst_us 实操（我试了 burst 但锯齿仍在，想确认是不是 burst 额度不够还是 period 边界本身的问题）
• id=1527 的 CPU Manager static 独占核（我试了独占但成本不划算，想看有没有中间方案）

这个问题和 id=1448（memory.high）是互补的：1448 问的是内存侧的软限，本问是 CPU 侧的软限，两者叠加才是 Burstable Pod 完整的资源预算策略。