前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >2021-03-05:go中,io密集型的应用,比如有很多文件io,磁盘io,网络io

2021-03-05:go中,io密集型的应用,比如有很多文件io,磁盘io,网络io

原创
作者头像
福大大架构师每日一题
修改2021-03-07 17:32:24
8060
修改2021-03-07 17:32:24
举报

2021-03-05:go中,io密集型的应用,比如有很多文件io,磁盘io,网络io,调大GOMAXPROCS,会不会对性能有帮助?为什么?

福哥答案2021-03-05:

这是面试中被问到的。实力有限,真正的答案还不知道。

答案1:

调节这个参数影响的是P的个数,也就影响了M(线程)干活的个数。相当于你可以有更多的执行线程。

先以网络io来说,网络io 在golang 里面是异步的,用epoll池做的io复用。每个网络调用其实都是异步的,发数据给到内存,调度权就可以让给其他goroutine了,所以,其实一个线程能处理过来的话,性能是不会差的,这个时候你加多P其实提升不大。只有你单线程处理不过来这些网络io的时候(每个都处理很慢),加多P才有明显提升

如果是磁盘io的话,这个有点特殊,磁盘io不是异步的,没有aio这种方式。所以你的磁盘io调用下去就卡住M了,这个时候等sysmon发现系统调用超时才会抢占M,这一来回就耗费时间了,所以,这种情况下你干活的M多一点确实能带来一些性能的提升,相当于并行干活的M多一些。

无论哪种情况,P的个数都不建议超过本机cpu的个数。因为多个cpu才是真正的并行执行,上层都是通过调度切换模拟出来的。

答案2:

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

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

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

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利用不足的开销。

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

GOMAXPROCS你设置对了吗?

go 协程详解

2021-03-05:go中,io密集型的应用,比如有很多文件io,磁盘io,网络i...如何解答呢?

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档