为什么80%的码农都做不了架构师？>>> 
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了。