Go — 容器内 CPU 节流：GOMAXPROCS 与配额不符

症状

　　延迟曲线呈锯齿状：平均值很低、周期性尖峰与 100ms 边界同步。两个数字合起来就是病灶：cgroup cpu.max 显示 200000/100000（每周期 2 CPU 配额），而 runtime.GOMAXPROCS(0) 报告 64（宿主机核数）——64 个调度线程加 GC worker 争抢 2 个 CPU 的配额。内核在周期早期就把配额烧光，随后冻结进程直到下个周期回填，这就是尖峰。凭证在 cpu.stat 里：nr_throttled 数万次、throttled_usec 累计 7.4 秒被冻结。

诊断思路

　　先对比运行时视角（GOMAXPROCS）与 cgroup 配额（cpu.max 或 v1 的 cfs_quota_us/cfs_period_us），一对数字完成诊断；再读 cpu.stat 的节流计数器，nr_throttled 与 throttled_usec 持续增长即内核在配额耗尽后冻结进程——延迟尖峰的直接原因；最后用 GOMAXPROCS=2 或 automaxprocs 验证尖峰消失，机制即被证实。

根因

　　Go 运行时按机器 CPU 数设定 GOMAXPROCS 与调度器，而容器执行的是 cgroup CPU 配额。失配之下大量可运行 OS 线程争抢零点几的核数；CFS 调度器在每周期早期耗尽配额并节流整个进程，产生周期性的毫秒级停顿。

修复与验证

　　让取值对齐配额：部署里显式设 GOMAXPROCS 环境变量等于 resources.limits.cpu（显式、可审计），或导入 go.uber.org/automaxprocs 在启动时自读 cgroup 限额（自适应、免维护）。对齐后注意二阶效应：GC 的专属 worker 变少，单次收集可能略变长而整体 p99 改善——延迟敏感服务要复查 GOGC 而不是默认它仍然合适。验证时在持续负载下断言节流计数器趋零、p99 失去周期性尖峰、GOMAXPROCS(0) 报告配额对齐值。把值硬编码进二进制会在改限额时失效——优先 automaxprocs 或从编排系统注入。

代码示例

$ cat /sys/fs/cgroup/cpu.max
200000 100000        <- quota 2 CPUs per 100ms period

$ kubectl exec pod -- go-env GOMAXPROCS   # or print runtime.GOMAXPROCS(0)
64                    <- the host core count

$ cat /sys/fs/cgroup/cpu.stat
nr_throttled 18402
throttled_usec 7439121067   <- 7.4 seconds spent frozen

env:
  - name: GOMAXPROCS
    value: "2"   # matches the resources.limits.cpu you declared

import _ "go.uber.org/automaxprocs" // reads cgroup quota at startup

func main() {
    // runtime.GOMAXPROCS now matches the container limit
}