httpd罢工问题的追踪

从hostker内测到现在一年半,httpd的各项参数我和运维也读了个遍不知道多少次,理论上不会因为配置的失误导致httpd出现异常现象。但是在日常运维中,发现一旦降低硬件配置,就可能出现httpd进程集体罢工不处理事件的问题。起初发现从httpd抛出core的文件可能可以进行分析,但是分析不出什么问题,百思不得其解,无奈只好搁置。直到上个月进行硬件升级后,依然出现httpd进程集体罢工不干活事件(虽然就一次,并且很快人工处理完)。觉得有必要从运维系统里查查问题,于是这几天开始摸爬滚打到处找资料想办法。

首先就是整天不断盯着监控图,先定位出问题~_~到8月30日,发现httpd进程出现异常:(黄色:free,蓝色:idle,绿色:busy)

httpd1

 

busy莫名其妙的多,多得直接无空闲进程提供服务导致警报响起,运维进行了多次人工重启后复活。由于现象比较频繁,暂时看不出是什么原因导致的。只好继续观察。

到⑨月3日,终于发现一个比较异常的现象。busy只升不降,并且进入半夜也出现这一情况。

httpd2

 

在人工restart后再次降回正常水平。此时我们把目光瞄到busy上,进程们都在干什么?

在下一个busy高峰,我们查看了apache的进程状态。得到的是满屏的G。G=Gracefully finishing。

不需要查资料也能知道,这个进程到了我们设置的请求阈值数,需要自杀了。

但是不知道什么原因,进程自杀失败,并且新进程无法派生。如果G堆满了全部的子进程,那么httpd自然要罢工。

问题找到了,接下来就是想办法解决。首先把矛头指向prefork,是不是进程管理出现什么bug进而导致这个情况出现?于是在昨天下午,把生产环境切入event模式。在event模式下可以很直观的观察到httpd进程的启动、自杀、派生子进程的过程。

结果很遗憾,event模式下每个进程都需要处理很多请求,很快达到我们设定阈值需要进行自杀。过几小时后,出现全屏G,警报出现,只好作罢,切回prefork。

无奈只好用python写一个小监控,随时查看G数量,超过一定数量直接重启httpd,这样就降低运维工作量了。但是httpd为何进程会自杀失败?查了许多资料无果=_=于是本文待更新,如果找到了解决方案会直接更新本文。

httpd罢工问题的追踪 有 9 个评论

    1. @千与琥珀 已经说了排除配置错误=.=权限有问题的话全部进程都别自杀了hostker早就瘫痪了,只是个别自杀失败。如果-⑨也杀不掉进程是Linux的错不是httpd的错了。。。

      1. @小新喵 此外可能性就是G太多,程序没有足够的可用资源kill了自己
        还有注意到了第一个图12点的时候,那一瞬间httpd在干什么?busy吃完真心很少见。其实这东东之前也没遇到过,还是待更新吧

发表评论

电子邮件地址不会被公开。 必填项已用*标注