golang密集场景下协程调度饥饿问题

rfyiamcool · · 1250 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

前言:

       前段时间跟一个滴滴的小哥聊了关于golang饥饿调度的话题,似乎大家觉得golang不会出现太长时间饥饿。 虽然大家看过golang sysmon抢占的源码实现,但不确定实际运行的结果是否跟预想的一致。 什么是饥饿调度,就是长时间得不到调度器来调度运行,  长时间算多长?这个时间是个相对值。 这里主要测试go在 cpu密集 和 非cpu密集 下的调度器表现。 当然,go里面做cpu密集计算是有些反社会的,go社区里也不推荐这么使用go,应该没人这么干吧 ? 

      我们知道golang是善于做的是服务端开发,大家写的服务端程序或多或少会有这些 network io, channel, disk io, sleep 调用什么的。这些的操作都会导致M跟G的解绑,并且M重新的获取可用G的调度。golang很多的syscall调用之前也会做一些解绑操作。也就是说,golang在正常的场景下似乎很难出现 同一组 MPG 长时间绑定的情况。另外,就算出现mpg长时间绑定运行,sysmon也会帮你做抢占,不管你是Psyscall, 还是Prunning状态。 

sysmon retake() 是怎么抢占的?

      起初runtime.main会创建一个额外的M运行sysmon函数, 抢占就是在sysmon中实现的. sysmon会进入一个无限循环, 第一轮回休眠20us, 之后每次休眠时间倍增,  最大不会超过10ms.  sysmon中有netpool(获取fd事件), retake(抢占), forcegc(按时间强制执行gc), scavenge heap等处理. 这里只说 retake 抢占。
      Sysmon会调用retake()函数,retake()函数会遍历所有的P,如果一个P处于Psyscall状态,会被调用handoffp来解绑MP关系。 如果处于Prunning执行状态,一直执行某个G且已经连续执行了 > 10ms的时间,就会被抢占。retake()调用preemptone()将P的stackguard0设为stackPreempt,这将导致该P中正在执行的G进行下一次函数调用时, 导致栈空间检查失败。进而触发morestack()然后进行一连串的函数调用,主要的调用过程如下:

golang的PMG怎么可能会一直处于Prunning状态,一般来说只有cpu密集场景才会吧…. (废话)

测试一把cpu密集场景

我先写了一个看起来是协程调度饥饿的例子。 为了高度模拟cpu密集的场景,脚本的逻辑很简单,spawn了10w个协程,每个协程不断的在循环计数, 协程初次和结束都会做一个atomic计数,好让监控协程支持大家都有被调度到。 当监控协程检测到大家都有被触发时, 退出.


另外,runtime.GOMAXPROCS为什么设置为 3 ? 运行的阿里云机器是 4core,  procs设为3,在cpu密集场景下应该是cpu 300%. sysmon是在一个独立出一个M也就是线程去执行,这样避免了4个core下cpu 400%的情况下,在满荷载下ssh登陆都是个问题,导致无法进行其他操作。

我们先看下CPU使用情况,跟我们想象中的结果是一样的几乎到了cpu 300% 


程序一直扔在tmux后台跑, 在等了两天之后,发现10w个协程中还有一些goroutine没有被调度到, 也就是说 程序一直还在运行着。 下面的截图是6个小时的cpu运行状态,因为监控系统存储误操作,清理了数据, 丢失了2天的图表。

为什么没有触发抢占?

为什么没有被触发? golang runtime sysmon代码看起来是10ms会发生触发一次抢占请求,  当然,当M处于处于正在分配内存或者非抢占模式下或其他原因,可能会跳过这次抢占。 但,6个小时过去了,依然有一些协程没有被调度到,这是什么原因?

上面sysmon原理的时候有提过,retake会触发 morestack, 然后调用 newstack, 然后gopreempt_m会重置g的状态,扔到runq并且重新调度. 关键点是 morestack ? goroutine stack默认是2kb, 而然我们的goroutine被spawn之后,基本是自己玩自己的,没有调用其他的function, 那自然stack没啥变化了,所以说,没有发生抢占.  runtime代码有说,morestack — > newstack才会真的触发抢占,我们加上一些有层次的函数调用, 让stack扩充不就行了。

使用了递归调用栈来迅速扩充stack大小。经过测试,下面的代码 在 2分钟 内 1w个协程都会被调度到的。


刚才不是10w个协程么,怎么又缩减1w了…  因为10w协程长时间没动静…..  可以说,go在cpu密集场景下,会产生协程饥饿调度的问题,单看我们的测试结果,所谓的饥饿调度还是有的。在几k的协程下没有看到饥饿调度现象, 几w的协程还有可以看出一定程度的饥饿。 

另外, 在CPU密集场景下,你调度器去均衡调度、抢占有个屁用呀,来回切换也有调度器自身产生的cpu消耗,还不如老老实实的处理完。要么加机器,要么优化算法。

讲道理,讲调度

先简单的描述下调度流程,首先空闲的M跟可用空闲的P绑定,然后从P的runq里获取可用的G, 当G长时间执行的时候,会被sysmon做retake()抢占,被中断的G会放到全局队列的尾部.  P的runq和全局的runq应该存有fifo的特性,按道理来说,应该都会被调度到呀, 只是时间长短而已…  我这里多次尝试过使用go tool pprof 或者 go tool trace 来追踪来分析原因,但又因为测试模拟了cpu密集,导致cpu打满的,所以 pprof和trace根本就调度不出来。。。

正常场景下,  10w个协程的调度情况

文章开头时,有说过 ! 正常场景很难出现MPG长时间绑定的情况,那么我们再来模拟测试下golang在正常场景下的调度表现 ?

方法1, 在cpu密集里加入一个time.Sleep(), 后台会调用gopark.

第二个,   在每组计算完成后主动触发goshed

第三个,    触发一个网络io操作.

这三种方法在在一个合理的时间里, 10w个协程都被触发调度了.  具体的耗时时间大家可以自己测一把, 这跟机器的cpu hz是有直接关系的.

总结

    这个所谓饥饿调度测试我承认有些无聊呀,也显得工作不饱和。实际工作中似乎除了机器学习,模型计算之外,似乎少有这样长时间cpu密集纯计算的场景了。但通过实验我们最少可以证明,golang retake抢占在 cpu密集场景下,上w 协程貌似不怎么管用 !   

    那么,在golang到底存不存在饥饿调度的问题? 正常使用golang的场景下,不会出现协程饥饿调度的问题。 但cpu bound场景下,饥饿调度现象还是有的。当然这里的测试方法还有待商榷,也不算严谨。


有疑问加站长微信联系(非本文作者)

本文来自:峰云就她了

感谢作者:rfyiamcool

查看原文:golang密集场景下协程调度饥饿问题

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1250 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传