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了。