先前在社区里分享了关于 golang 行情推送[1]的分享,有人针对 ppt 的内容问了我两个问题,一个是在 docker 下 golang 的 gomaxprocs 初始化混乱问题,另一个是 golang runtime.gomaxprocs 配置多少为合适?
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。
在微服务体系下服务的部署通常是放在 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 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 g
if 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 可以分析出协程调度等待时间越来越长了。
有两个方法可以准确校对 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