beego在docker中跑得慢、cpu忽高忽低、p99毛刺多，主因是gomaxprocs默认取宿主机核数（如32），而容器仅限0.5核，导致32个p争抢调度，runtime.mcall和上下文切换吃掉大量cpu。
Beego 在 Docker 容器里跑得慢、CPU 利用率忽高忽低、p99 延迟毛刺多，大概率不是 Beego 本身的问题，而是 GOMAXPROCS 拿的是宿主机核数，和容器实际 CPU 配额完全脱节——它让 32 个 P 在 0.5 核上抢调度，runtime.mcall 和上下文切换直接吃掉一半 CPU 时间。
为什么 Beego 启动后 GOMAXPROCS 还是宿主机核数
Beego 是基于 net/http 的框架，自身不干预 Go 运行时初始化。Docker/K8s 中：runtime.NumCPU() 默认读 /proc/cpuinfo，返回的是宿主机逻辑核数，不是容器的 cfs_quota_us / cfs_period_us。哪怕你 kubectl set resources 限了 limits.cpu: "1000m"，Beego 进程启动时仍会设 GOMAXPROCS=32（假设宿主机 32 核）。
- 检查方式：在
func main()开头加fmt.Println("GOMAXPROCS =", runtime.GOMAXPROCS(0))，看输出是否等于你期望的 vCPU 数 - 常见干扰源：Beego 的插件（如
bee工具链、某些 metrics 中间件）、第三方日志库（如logrus+ hook）、甚至go-sql-driver/mysql的 init 函数都可能偷偷调用runtime.GOMAXPROCS - Alpine 镜像注意：
/sys/fs/cgroup/cpu/cpu.cfs_quota_us在 cgroup v2 下路径是/sys/fs/cgroup/cpu.max，Go 1.19+ 才原生支持；老版本需手动 fallback
Beego 应用该设多少 GOMAXPROCS
Beego 多为 I/O 密集型 HTTP 服务（路由分发、JSON 编解码、DB 查询），不是纯计算任务。盲目设高值反而抬高调度开销，尤其当请求中混有同步阻塞操作（如未设超时的 http.Client.Do、全局 sync.Mutex、无缓冲 channel）时，P 多了也得排队等。
- CPU 限制为
1000m（即 1 核）：优先试GOMAXPROCS=1或2；压测看 p99 是否更稳，go tool trace中 “Proc status” idle 占比若长期 >70%，说明 P 过剩 - CPU 限制为
2000m（2 核）且含图像处理/聚合计算：可设GOMAXPROCS=2，再用pprof cpu看runtime.scanobject或encoding/json.(*decodeState).object是否占热点，仅当 CPU 密集部分占比高才考虑微增至 3 - 别信 “Beego 要高并发就得开 8 个 P” —— 它的 goroutine 已由
net/http.Server自动派发，每个请求一个 goroutine，再多 P 只是增加 steal 成本
Beego 的 http.Server 和 http.Client 必须配对调优
Beego 内置的 http.Server 默认无超时，而 Beego 应用常作为中间层调用下游服务，若 http.Client 未自定义 Transport，连接池失效、TLS 握手重试、慢响应堆积会直接拖垮整个 P 的本地队列。
- 服务端必设三项超时：
beego.BeeApp.Server.ReadTimeout（防慢请求占连接）、.WriteTimeout（防响应写卡住）、.IdleTimeout（清理空闲 keep-alive 连接，避免TIME_WAIT暴涨） - 客户端必须替换默认 transport：
http.DefaultClient无复用，每个请求新建 TCP+TLS；应定义全局client := &http.Client{Transport: &http.Transport{MaxIdleConns: 100, MaxIdleConnsPerHost: 100, IdleConnTimeout: 30 * time.Second}} - Beego 的
beego.HttpGet等快捷方法底层仍走http.DefaultClient，务必改用自定义client实例
验证 Beego 的 GOMAXPROCS 是否真生效且没副作用
光在代码里写 runtime.GOMAXPROCS(2) 不代表它起作用，更不代表它适合当前负载。真实瓶颈常藏在调度器行为或 GC 压力里。
- 启动后立刻打日志：
fmt.Printf("GOMAXPROCS=%d, NumCPU=%d\n", runtime.GOMAXPROCS(0), runtime.NumCPU())，确认两者差异是否符合预期 - 用
go tool trace看 Scheduler 视图：P 数量是否匹配设置值；若大量 P 长期处于idle状态（>50% 时间），说明设高了；若频繁出现gc pause且runtime.mcall占比突增，很可能是 P 过多导致栈分配压力大 - 压测对比关键指标：QPS 不变但 p99 延迟升高 20% 以上 → 高概率是
GOMAXPROCS过大；CPU 利用率低于 30% 但请求排队 → 检查是不是ReadTimeout太短或下游阻塞
最易被忽略的一点：Beego 的 RunMode 为 dev 时会启用文件热重载和模板自动编译，这些操作本身是同步阻塞的，会卡住整个 P 的本地队列——生产环境务必设 runmode = prod，否则所有调优都白搭。
