【GO 语言】合理配置 GOMAXPROCS 提升一倍以上的性能

GOMAXPROCS 用默认的，就是 CPU 的硬件线程数目，

对于大部分 File IO 密集的应用是不合适的。

至少应该配置到硬件线程数目的 5 倍以上, 最大 1024。

具体参见。

这是为什么呢？

我们来复习下 Go 的线程模型，M/P/G 三种对象，分别代表 操作系统线程、协程执行令牌、协程；

在任何情况下，Go 运行时并行执行（注意，不是并发）的 goroutines 数量是小于等于 P 的数量的。

如果一个持有 P 的 M，由于 P 当前执行的 G 调用了 syscall 而导致 M 被阻塞，那么：

注意

注意

注意

关键点：此时，GO 的调度器是迟钝的，它很可能什么都没做，直到 M 阻塞了想当长时间以后，才会发现有一个 P/M 被 syscall 阻塞了。然后，才会用空闲的 M 来强这个 P。

补充说明：调度器迟钝不是 M 迟钝，M 也就是操作系统线程，是非常的敏感的，只要阻塞就会被操作系统调度（除了极少数自旋的情况）。但是 GO 的调度器会等待一个时间间隔才会行动，这也是为了减少调度器干预的次数。也就是说，如果一个 M 调用了什么 API 导致了操作系统线程阻塞了，操作系统立刻会把这个线程 M 调度走，挂起等阻塞解除。这时候，Go 调度器不会马上把这个 M 持有的 P 抢走。这就会导致一定的 P 被浪费了。

这就是为何，GOMAXPROCS 太小，也就是 P 的数量太少，会导致 IO 密集(或者 syscall 较多)的 go 程序运行缓慢的原因。

那么，GOMAXPROCS 很大，超过硬件线程的 8 倍，会不会有开销呢？

答案是，开销是有的，但是远小于 Go 运行时迟钝的调度 M 来抢夺 P 而导致 CPU 利用不足的开销。

P.S.

本文至少对 Go 1.8 版本是有效的。

P.S.

其实，这也是经典的长肥管道问题，由于 SSD 的普及，IO 操作从高延时低吞吐，变成了中高延时高吞吐。

一次 SSD IO 的延时在 1ms，而一块企业级 SSD 的吞吐在 100Kops，那么在队列里面的操作就有 100 个。

操作系统在 1ms 内可以完成很多次线程调度（一般情况 1ms 可以完成几十次线程调度），但是 Go 的运行时，最大的阻塞发现延时是 10ms。

于是，当一个 Go 的协程发起一次 SSD IO 时，执行该 G 的 M 会阻塞然后被 OS 调度走，该 M 一直持有 P。在 1ms 内，这次 SSD IO 很可能不会完成。Go 的运行时，最快在 20us，最慢在 10ms 会发现有一个 M 持有 P 并阻塞了。运气不好的话，很可能，Go 运行时 2ms 才扫描一次，于是没来得及发现这个阻塞的 M，阻塞就结束了。宝贵的 P 资源就这么被阻塞的 M 浪费了。SSD IO 的 ops 上限变成了

*P 的数量 （1s/IO 延时）

当 P 的数量小于 100，IO 延时 1ms 的时候，ops 就肯定小于 100Kops 了。