Go gomaxprocs 调高引起调度性能损耗

梦醒人间

发布于 2021-07-16 11:13:28

1.9K0

发布于 2021-07-16 11:13:28

文章被收录于专栏：码农桃花源

先前在社区里分享了关于 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 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）明显多起来，另外等待调度的线程也多了。