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

原创
2017/08/07 20:58
阅读数 1.8W
AI总结

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

 

 

 

 

 

 

 

展开阅读全文
加载中
点击加入讨论🔥(7) 发布并加入讨论🔥
7 评论
2 收藏
2
分享
AI总结
返回顶部
顶部