前言:

        这节主要是聊聊怎么快速定位到问题,并解决问题的。 这次问题更多的是由于造了一个连接池轮子,然后自己坑自己。 事情是这样,一堆Ops找我,说我的任务派发系统连接数高达2w, 还都是established已经建立连接的,其他time-wait, close-wait 这类中间状态很少。 另外该系统是分布式的,每个机房都有几个proxy节点,算起来全网最少有几百个节点了。 下面是某个主机当时的连接数情况,当前的qps在7000左右,但后端连接的主机也才几十台… 



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


      值得幸运的是出现这类连接暴涨的节点不到十台,而且不是主调度节点。  幸运完了,就说明下怎么分析问题的吧? 首先想,为什么以前没有这情况?  根据监控图表可以分析出,以前不管是连接数,cpu,内存,包括业务的任务量都不大,随着任务量暴增后,节点就不够用了,作为任务系统就需要承载更多的并发。


      我的服务框架是多进程+协程池的方案,所以strace的维度只能是一个进程了。 通过观察,每次子进程处理一个量级后,由master重新实例化子进程的时候,子进程会很疯狂的去建立连接。 然而过一段时间平稳期后,就不会重新建立连接。 再次通过lsof 和 strace 比对文件描述符,发现平稳期内一直在复用以前的连接。 这说明什么? 说明连接池看起来没有问题的。


    既然看起来没问题,那么为毛会干到2w的连接数,还不只是一台服务器这样 ?  再次对比lsof的文件描述符,发现相同的主机建立了有30多个连接…  那么继续往下推,根绝我的经验,会建立这么多连接只有一种情况,就是并发太高,python requests连接池是借用urllib2 pool实现的,里面主要是靠tcp的四元组来匹配,当某个协程拿到连接之后,另一个协程并发执行发现没有可用的连接,那么他会重新new一个连接,当然这要看是否触发到requests 适配器的连接池的大小,不可能让他无限的暴增。



       统计日志分析出并发量比先前大了不少,区间内峰值,每秒QPS已经提升到11000左右了。但问题是,并不是后端主机的任务都这么多,任务量零零散散的主机,为什么也会实例化创建这么多的http连接。 另外,连接数跟进程内的协程数几乎同一,但基本没有不会超过协程数。 这里,问题差不多可以猜出来了,协程之间没有共用这个连接池。如果是共用一个池,那么理想状态是,针对某个后端主机有几个并发,就应该有几个http连接。 连接数太多造成的直接问题就是,你的主动连接端口不够用,因为一个源ip发起的端口数只有65535,除去预留,那更少了….  

回溯历史

    问题的核心是 协程之间没有共用连接池。 项目的初期,我用的是requests这么非常human的库,但他最大的问题就是性能 !!!  封装过多,另一方面他底层的urllib2的http protocol parser性能也不行。 在暴力压测的场景下,cpu奇高无比,各类性能分析可以确定http parse有不少的性能损耗责任。 后来选过一些性能相对高端但是比较难用的http client, 像uvloop的httptools、fasthttp、meinheld http client,在压测环境下性能还是很客观,最少cpu不会吃的那么高。但是他们的最大问题是,连接池都好用,小问题不少… 

    后来索性自己实现一组连接池,当初因为是着急退换requests,各方面考虑不周,没有加入线程安全维度,只能暂时每个协程实例化连接,规避线程安全问题,这也是问题根源所在….  退回到requests的时候,中间也遇到一个问题,就是连接数不够用,他可能会阻塞 ? 如果你默认开启了最大限制及block选项,怎么算单个进程的最大的连接数 ?   协程数 * 后端主机数 =  最大连接数.   因为你要想到一个问题,所有的协程都在并发请求一个主机…. 对于一个高频的服务来说,连接数过几千是很正常的事情.   

监控图

下图是tcp连接数暴涨的趋势图,后面是我找到原因,并重新打包上线后的情况。连接数已经降低到 2k 左右了。


总结:

     老人常常说,造轮子是有风险的….  好像是这么一回事…  好在,发现问题到解决问题,半小时搞定 …

END.



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

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

评论已关闭。