解决多进程模式下引起的“惊群”效应

导语: 对不起,我是标题党,本文解决的不是我们理解的“惊群”效应,先为我们操作系统组的正下名,因为腾讯服务器的内核版本,已经解决epoll模式下的惊群现象(本文描述的现象跟惊群其实基本一致)。接下来容我详细道来这个是什么形式的“惊群”效应并如何解决。

缘起

最近很无聊,突然登录线上的某台机器,发现服务进程的CPU占用率很不一样,详细如下图:

为什么会出现这种情况呢?那到底会不会造成线上服务不稳定。然后自己通过webbench压测了一波,发现所有请求都很正常,一个请求都没丢失,而且时延也非常完成。好吧,心头大石放下,还以为还要背个事故呢。

目前调度不均衡的情况,是请求量比较少导致的。猜想,如果我把请求量压上来,进程的调度均衡情况会不会被改善呢?再压测了一波,把所有进程都压到一个相对高的CPU占用率,竟然发现各个进程的调度情况均衡了,但还是有一些差异。

猜测

然后自己一直纠结着是不是因为Linux的惊群导致。先分析下系统的内核版本,本来测试的机器是前段时间才重装的系统,应该已经解决了惊群的了啊。咋一看,内核版本已经是修复了惊群现象版本(3.10>2.6)。

惊群简单来说就是多个进程或者线程在等待同一个事件,当事件发生时,所有线程和进程都会被内核唤醒。唤醒后通常只有一个进程获得了该事件并进行处理,其他进程发现获取事件失败后又继续进入了等待状态,在一定程度上降低了系统性能。

好吧,本来想甩下锅给操作系统组的,直接去问操作系统组为什么会出现惊群的,看来还是保留点自尊吧。

那,到底是什么原因导致的呢?先strace看看某个进程什么情况: 

怎么进程会accept失败了……这不科学啊,压测工具的响应也是正常的,线上也没人反馈过出问题,应该这个是正常的逻辑。

分析

进程为啥会出现竞争效应呢?先看看所有进程的情况:

同一个设备id?所有进程都在同一个队列竞争资源。分析了下服务的代码创建多进程,具体流程是这样的:

这种方式创建多进程,在父进程创建完socket以后才fork出来,内核肯定clone同一个设备id啊。那为什么同一个设备id就会导致资源分配不均衡呢?下面我们分析下:

首先,进程epoll模式是设置了LT模式,LT模式下,每接收一个请求,内核都会唤醒进程进行接收。然而,所有子进程都是共享一个设备id,换句话来说,只能由一个进程把请求读出并处理,其他进程只是一个空转状态。因此,就会出现上面各个子进程的调度不均衡的情况,其实,这种情况我自己认为也是惊群效应,所有服务进程都被惊醒,但是accept出来是EAGAIN。但具体为什么都是某个进程占用的CPU更高,这个应该是由内核决定,具体原因我也不太清楚。

好吧,稍微修改一下:

fork();

create_listen_socket();

loop();

不幸的是,这样是启动不起来的!

详细分析了下:socket创建的时候,设置了REUSEADDR,所以原来创建多进程的,是能启动起来,因为端口公用了一个设备id。但是先fork在createsocket,端口被占用了,那能不能设置REUSEPORT。两者的区别,网上稍微搜一下就有相关资料了,具体差别是在于:SO_REUSEADDR主要改变了系统对待通配符IP地址冲突的方式,而SO_REUSEPORT允许将任意数目的socket绑定到完全相同的源地址端口对上。

然后尝试设置REUSEPORT参数,结果也是不尽人意,编译出错。

 原来,REUSEPORT是只有在3.9以上的内核版本才支持,我的开发机是2.6,应该不支持这次编译。

继续深挖

好吧,问题还是不能解决,请教了一些操作系统组的高手,建议使用ET模式去解决一下这个惊群效应。修改了框架代码,编译了一个ET模式的服务进程,进行压测,webbench丢包非常严重,1000/s的包只能处理几个。ET模式是不是不通用呢?我们先看下ET的具体说明:

ET模式下accept存在的问题,考虑这种情况:多个连接同时到达,服务器的TCP就绪队列瞬间积累多个就绪连接,由于是边缘触发模式,epoll只会通知一次,accept只处理一个连接,导致TCP就绪队列中剩下的连接都得不到处理。

解决办法是用while循环抱住accept调用,处理完TCP就绪队列中的所有连接后再退出循环。如何知道是否处理完就绪队列中的所有连接呢?accept返回-1并且errno设置为EAGAIN就表示所有连接都处理完。

这样就明了了,多个请求同时唤醒一个进程,而我的accept是没有循环处理的, ET边缘触发导致多个请求操作系统只通知了一次,而逻辑才进行了一次处理,所以导致队列的包没被接收处理,从而导致丢包。

接下来改造系统,ET模式下,循环accept。OK,请求都被accept成功,但是,还是会触发EAGAIN,而且多进程之间也是调度不均衡的。(https://blog.csdn.net/dog250/article/details/80837278里面是某大神总结的,是可以通过ET模式解决LT模式的惊群现象,但是我把代码编译测试了一遍,确实还是会触发惊群,但频率没那么高,估计大神的测试代码是因为业务逻辑是空的原因导致)。

峰回路转

 什么ET/LT模式都尝试过了,还是解决不了多进程之前调度不均衡的问题,想着反正不影响(原理上来说,空转情况下确实是会浪费点CPU),准备想放弃。但最后还是想尝试一下,把socket句柄设置成15(SO_REUSEPORT=15),自己定义了一个宏,然后修改了fork逻辑:

fork();
socket = create_listen_socket();
set_sock_opt(socket,SO_REUSERPORT);
loop();

启动进程,成功了!但是具体原因是为啥,机器的操作系统是不支持SO_REUSEPORT的,问下了操作系统的同事,给到的答复是目前的操作系统是打了上游的patch。再细问一下,标准库的头文件也没有SO_REUSEPORT的定义。给到的答复是头文件和内核不同步。好吧,其实我很不愿意接受了这个答复。最后的一个问题,那这样我如何确保我的所有机器是否支持SO_REUSEPORT,给到的答复是只能测试了。

经过一轮发布,发现所有机器都支持这个参数,而且进程已经支持了多进程之间的调度均衡。

另外,通过fork的顺序,也确认了每个进程管理自身的设备id,也不会出现惊群现象(不会再出现accept EAGAIN),原因是REUSEPORT,侦听同一个IP地址端口对的多个socket本身在socket层就是相互隔离的,在它们之间的事件分发是TCP/IP协议栈完成的,所以不会再有惊群发生。

写在最后

多进程情况下,都建议使用REUSEPORT,就不会出现那么多不稳定的问题。

本站文章资源均来源自网络,除非特别声明,否则均不代表站方观点,并仅供查阅,不作为任何参考依据!
如有侵权请及时跟我们联系,本站将及时删除!
如遇版权问题,请查看 本站版权声明
THE END
分享
二维码
海报
解决多进程模式下引起的“惊群”效应
容我详细道来这个是什么形式的“惊群”效应并如何解决。
<<上一篇
下一篇>>