先前在社区里分享了关于 golang 行情推送^[1]的分享，有人针对 ppt 的内容问了我两个问题，一个是在 docker 下 golang 的 gomaxprocs 初始化混乱问题，另一个是 golang runtime.gomaxprocs 配置多少为合适？

golang runtime

Golang 的 runtime 调度是依赖 pmg 的角色抽象，p 为逻辑处理器，m 为执行体(线程)，g 为协程。p 的 runq 队列中放着可执行的 goroutine 结构。golang 默认 p 的数量为 cpu core 数目，比如物理核心为 8 cpu core，那么 go processor 的数量就为 8。另外，同一时间一个 p 只能绑定一个 m 线程，pm 绑定后自然就找 g 和运行 g。

那么增加 processor 的数量，是否可以用来加大 runtime 对于协程的调度吞吐？

大多 golang 的项目偏重网络 io，network io 在 netpoll 设计下都是非阻塞的，所涉及到的 syscall 不会阻塞。如果是 cpu 密集的业务，增加多个 processor 也没用，毕竟 cpu 计算资源就这些，居然还想着来回的切换？???? 所以，多数场景下单纯增加 processor 是没什么用的。

当然，话不绝对，如果你的逻辑含有不少的 cgo 及阻塞 syscall 的操作，那么增加 processor 还是有效果的，最少在我实际项目中有效果。原因是这类操作有可能因为过慢引起阻塞，在阻塞期间的 p 被 mg 绑定一起，其他 m 无法获取 p 的所有权。虽然在 findrunnable steal 机制里，其他 p 的 m 可以偷该 p 的任务，但在解绑 p 之前终究还是少了一条并行通道。另外，runtime 的 sysmon 周期性的检查长时间阻塞的 pmg， 并抢占并解绑 p。

golang 在 docker 下的问题

在微服务体系下服务的部署通常是放在 docker 里的。一个宿主机里跑着大量的不同服务的容器。为了避免资源冲突，通常会合理地对每个容器做 cpu 资源控制。比如给一个 golang 服务的容器限定了 2 cpu core 的资源，容器内的服务不管怎么折腾，也确实只能用到大约 2 个 cpu core 的资源。

但 golang 初始化 processor 数量是依赖 /proc/cpuinfo 信息的，容器内的 cpuinfo 是跟宿主机一致的，这样导致容器只能用到 2 个 cpu core，但 golang 初始化了跟物理 cpu core 相同数量的 processor。

// xiaorui.cc限制2核左右
root@xiaorui.cc:~# docker run -tid --cpu-period 100000 --cpu-quota 200000 ubuntu容器内
root@a4f33fdd0240:/# cat /proc/cpuinfo| grep "processor"| wc -l
48

runtime processor 多了会出现什么问题？

一个是 runtime findrunnable 时产生的损耗，另一个是线程引起的上下文切换。

runtime 的 findrunnable 方法是解决 m 找可用的协程的函数，当从绑定 p 本地 runq 上找不到可执行的 goroutine 后，尝试从全局链表中拿，再拿不到从 netpoll 和事件池里拿，最后会从别的 p 里偷任务。全局 runq 是有锁操作，其他偷任务使用了 atomic 原子操作来规避 futex 竞争下陷入切换等待问题，但 lock free 在竞争下也会有忙轮询的状态，比如不断的尝试。

// xiaorui.cc// 全局 runq
if sched.runqsize != 0 {lock(&sched.lock)gp := globrunqget(_p_, 0)unlock(&sched.lock)if gp != nil {return gp, false}
}
...// 尝试4次从别的p偷任务for i := 0; i < 4; i++ {for enum := stealOrder.start(fastrand()); !enum.done(); enum.next() {if sched.gcwaiting != 0 {goto top}stealRunNextG := i > 2 // first look for ready queues with more than 1 gif gp := runqsteal(_p_, allp[enum.position()], stealRunNextG); gp != nil {return gp, false}}
}
...

通过 godebug 可以看到全局队列及各个 p 的 runq 里等待调度的任务量。有不少 p 是空的，那么势必会引起 steal 偷任务。另外，runqueue 的大小远超其他 p 的总和，说明大部分任务在全局里，全局又是把大锁。

随着调多 runtime processor 数量，相关的 m 线程自然也就跟着多了起来。linux 内核为了保证可执行的线程在调度上雨露均沾，按照内核调度算法来切换就绪状态的线程，切换又引起上下文切换。上下文切换也是性能的一大杀手。findrunnable 的某些锁竞争也会触发上下文切换。

下面是我这边一个行情推送服务压测下的 vmstat 监控数据。首先把容器的的 cpu core 限制为 8，再先后测试 processor 为 8 和 48 的情况。图的上面是 processor 为 8 的情况，下面为 processor 为 48 的情况。看图可以直观地发现当 processor 调大后，上下文切换（cs）明显多起来，另外等待调度的线程也多了。

另外从 qps 的指标上也可以反映多 processor 带来的性能损耗。通过下图可以看到当 runtime.GOMAXPROCS 为固定的 cpu core 数时，性能最理想。后面随着 processor 数量的增长，qps 指标有所下降。

通过 golang tool trace 可以分析出协程调度等待时间越来越长了。

解决 docker 下的 golang gomaxprocs 校对问题

有两个方法可以准确校对 golang 在 docker 的 cpu 获取问题。

要么在 k8s pod 里加入 cpu 限制的环境变量，容器内的 golang 服务在启动时获取关于 cpu 的信息。

要么解析 cpu.cfs_period_us 和 cpu.cfs_quota_us 配置来计算 cpu 资源。社区里有不少这类的库可以使用，uber的automaxprocs^[2]可以兼容 docker 的各种 cpu 配置。

总结

建议 gomaxprocs 配置为 cpu core 数量就可以了，Go 默认就是这个配置，无需再介入。如果涉及到阻塞 syscall，可以适当的调整 gomaxprocs 大小，但一定要用指标数据说话！

参考资料

[1]

行情推送: http://xiaorui.cc/?p=6250

[2]

automaxprocs: https://github.com/uber-go/automaxprocs