前言:

       我们知道golang对用户抽象了协程,协程要跑起来必然是需要系统线程来承载上下文,因为线程是最小的调度单元。golang的scheduler会帮你调度关联 PMG,这里的M是线程,G就是我们在golang里用go关键字spawn的协程。 对于用户来说,你是看不到也无法创建native thread原生线程的。 不管是golang nuts和golang issue里有人提过native thread feature的需求,但社区给出的论调是没必要,如果有必要那么可以用cgo,或者手动触发runtime.LockOSThread绑定。

       该文章后续仍在不断的更新修改中, 请移步到原文地址  http://xiaorui.cc/?p=5171

       有些跑题,接着来。 golang抽象了pmg,  我们通常不会特意的去关注某个golang线程数目,但上次就遇到了golang线程异常暴增, 最多的时候涨到1300多个线程。那我们知道线程过多有什么问题? 每个pthread的stack栈空间是8MB, 当然是virt,  这些线程也会增加kernel的调度成本,光上下文切换就不是闹的。当然golang 不会这么傻,不会让这么多的线程去轮询P上下文队列, 应该会有条件变量去控制调度。


golang 线程暴增的原因?

     什么问题会导致产生这么多的线程? 我先告诉大家答案,在我的这个场景下是 因为磁盘io问题引起的。 因为一些杂七杂八的程序都在这台主机,iops过高,又因为是阿里云磁盘性能低下,又又因为内存被占用的差不多了…. 

     首先我们知道 golang写文件是阻塞,后面会说明原因。当我们写日志一般是先写到内核的page cache里,然后再由kernel通过阈值或定时刷新到磁盘,而不会像数据库那样调用fsync来磁盘落地。

     既然先写到page cache内存里应该很快呀。 但这台服务器上有不少相关的服务在跑,在压测的场景下会产生大量的日志,而大量的日志都会扔到page cahe里,但刚才说了不少相关的服务都在一台阿里云主机上,虽然这台阿里云是高配,但相关服务都是吃内存不吐骨头的角色,导致page cache的内存明显少了。既然内存少了,那么kernel调用sync来持久化,但又因为阿里云主机的磁盘io吞吐很可悲,导致不能很快的flush到磁盘上。 那么就导致golang写日志的线程越来越多。




     golang runtime是有个sysmon的协程,他会轮询的检测所有的P上下文队列,只要 G-M 的线程长时间在阻塞状态,那么就重新创建一个线程去从runtime P队列里获取任务。先前的阻塞的线程会被游离出去了,当他完成阻塞操作后会触发相关的callback回调,并加入回线程组里。简单说,如果你没有特意配置runtime.SetMaxThreads,那么在可没有复用的线程下会一直创建新线程。 golang默认的最大线程数10000个线程,这个是硬编码。 如果想要控制golang的pthread线程数可以使用 runtime.SetMaxThreads() 。




golang 磁盘io问题?

        golang针对网络io使用了epoll事件机制来实现了异步非阻塞,但磁盘io用不了这套,因为磁盘始终是就绪状态,epoll是根据就绪通知,就绪 & 非就绪状态。 现在常见的一些高性能框架都没有直接的解决磁盘io异步非阻塞问题。 像nginx之前读写磁盘会阻塞worker进程,只有开启aio及线程池thread才会绕开阻塞问题。 可以说,整个linux下,aio不是很完善,最少比bsd和windows平台下稍微差点。像windows下iocp就解决了磁盘io异步问题,但他的原理关键也是线程池。


如何分析问题?

      下面说下分析问题的过程,  首先通过ps和pprof看到golang的线程数,然后通过golang stack分析出当前的调用栈逻辑,继而通过strace来追踪系统调用情况。 golang stack没啥好说的,写日志阻塞那么调用栈里会显示不少log的调用情况。 那么我们主要来分析下,写日志和创建线程是怎么做的关联 ?  很简单就两个工具,一个是strace, 一个是 lsof 。

通过strace是可以看到write(8) fd的时候会mmap mprotect clone创建线程, 通过lsof 可以看到8是一个日志文件。配合Prometheus监控是可以看出iostat过高的时候,线程的数目也会跟着增长起来。 因为其他原因系统的内存也在减少,所以引起page cache不断刷盘。

golang 内置pprof的截图,我们可以看到1009个线程.


PS命令看到的线程数, 可以看到数目跟pprof是一致的。


当前的磁盘io使用情况, utils表示 长时间io吞吐 100%


通过Prometheus查看io wait的趋势,  下面的图表可以看出io等待时间还是蛮高的。


怎么解决?

上面说了,磁盘io造成golang线程暴涨是有很多原因的? 比如内存太小呀,日志输出太多呀,磁盘吞吐不行呀,各种各样的。 

我们的解决方法是 首先限制runtime的线程数为200个 ( runtime.SetMaxThreads ),一般正常情况下都够用了。 通常24 core cpu的环境下,一个高频的proxy服务正常压测也才80多个线程。 这里主要还是为了避免预防各种未知诡异问题。 

另外线上把服务的日志级别调高到warn警告,别整个debug level,导致io疯狂输出。

据我的测试,剩余的内存如果够大,也是可以减少线程的异常增长, 毕竟写日志O_APPEND按道理是速度很快的顺序io。 

fsync & sync

    还有一点,我先前使用过 golang的boltdb作为nosql存储,当机器磁盘的io吞吐不够的时候,也会产生线程过多的情况。当然数目没有1000,那时候也有400多个线程了。

    像boltdb当然不会实时的去修改b+tree数据文件, 而是采取绝大数db的wal日志模式。 wal虽然是顺序io,但他的wal日志是通过fsync的方式来落盘的。 通过我们写日志是通过sync方法写,也就是数据写到内存page cache就完事了,这里更改的脏页不会立即落盘,而是等kernel的flusher定时或者触发阈值来刷盘。

    刷盘的时候也只是把写请求放到设备的io请求队列里。 中间只有有一个环节crash掉,那么就拉稀了。这个fsync的功能就是确保文件修改的内容安全的同步到硬盘上,该调用会阻塞等待直到设备报告IO完成。  要注意,又是同步,又是阻塞等待,我想你懂了。

    boltdb后面的版本貌似解决了该问题,具体修改的逻辑没看,有兴趣的朋友可以看看。记得告诉我。

总结:

      到此为止,golang线程暴增的问题差不多说完了。写这篇文章废了不少时间,其实发现问题 到 解决问题,一共也才十来分钟。 当大家遇到一些性能问题时,使用golang pprof及性能工具来检查, 比较容易就可以定位问题。推荐大家使用Prometheus来监控系统,通过golang metrics模块可以把runtime信息及业务上的qps输出到Prometheus里。 当有问题的时候,配合前端利器grafna可以多维度来分析问题。 

END.



对Python及运维开发感兴趣的朋友可以加QQ群 : 478476595 !!!
{ 2000人qq大群内有各厂大牛,常组织线上分享及沙龙,对高性能及分布式场景感兴趣同学欢迎加入该QQ群 }

另外如果大家觉得文章对你有些作用!   帮忙点击广告. 一来能刺激我写博客的欲望,二来好维护云主机的费用.
如果想赏钱,可以用微信扫描下面的二维码. 另外再次标注博客原地址  xiaorui.cc  ……   感谢!
暂无相关产品

评论已关闭。