httpd罢工问题的追踪
从hostker内测到现在一年半,httpd的各项参数我和运维也读了个遍不知道多少次,理论上不会因为配置的失误导致httpd出现异常现象。但是在日常运维中,发现一旦降低硬件配置,就可能出现httpd进程集体罢工不处理事件的问题。起初发现从httpd抛出core的文件可能可以进行分析,但是分析不出什么问题,百思不得其解,无奈只好搁置。直到上个月进行硬件升级后,依然出现httpd进程集体罢工不干活事件(虽然就一次,并且很快人工处理完)。觉得有必要从运维系统里查查问题,于是这几天开始摸爬滚打到处找资料想办法。
首先就是整天不断盯着监控图,先定位出问题~_~到8月30日,发现httpd进程出现异常:(黄色:free,蓝色:idle,绿色:busy)
busy莫名其妙的多,多得直接无空闲进程提供服务导致警报响起,运维进行了多次人工重启后复活。由于现象比较频繁,暂时看不出是什么原因导致的。只好继续观察。
到⑨月3日,终于发现一个比较异常的现象。busy只升不降,并且进入半夜也出现这一情况。
在人工restart后再次降回正常水平。此时我们把目光瞄到busy上,进程们都在干什么?
在下一个busy高峰,我们查看了apache的进程状态。得到的是满屏的G。G=Gracefully finishing。
不需要查资料也能知道,这个进程到了我们设置的请求阈值数,需要自杀了。
但是不知道什么原因,进程自杀失败,并且新进程无法派生。如果G堆满了全部的子进程,那么httpd自然要罢工。
问题找到了,接下来就是想办法解决。首先把矛头指向prefork,是不是进程管理出现什么bug进而导致这个情况出现?于是在昨天下午,把生产环境切入event模式。在event模式下可以很直观的观察到httpd进程的启动、自杀、派生子进程的过程。
结果很遗憾,event模式下每个进程都需要处理很多请求,很快达到我们设定阈值需要进行自杀。过几小时后,出现全屏G,警报出现,只好作罢,切回prefork。
无奈只好用python写一个小监控,随时查看G数量,超过一定数量直接重启httpd,这样就降低运维工作量了。但是httpd为何进程会自杀失败?查了许多资料无果=_=于是本文待更新,如果找到了解决方案会直接更新本文。
进程自杀失败一般是给的权限不够,试试看手工强杀有效不?
不过满屏的G,很蛋疼
@千与琥珀 已经说了排除配置错误=.=权限有问题的话全部进程都别自杀了hostker早就瘫痪了,只是个别自杀失败。如果-⑨也杀不掉进程是Linux的错不是httpd的错了。。。
@小新喵 此外可能性就是G太多,程序没有足够的可用资源kill了自己
还有注意到了第一个图12点的时候,那一瞬间httpd在干什么?busy吃完真心很少见。其实这东东之前也没遇到过,还是待更新吧
@千与琥珀 呃,此外swap你给了多少?
太久没碰这方面,都快忘光了( ̄▽ ̄”)
@千与琥珀 busy吃完遇到好多次了,G被归在busy。swap从来没吃过
@小新喵 我怀疑全成僵尸了,top能看到daemon吗?(不过能用-⑨Kill掉,真心无解了……
@千与琥珀 top当然能看到,而且不是僵尸
说好的更新呢
@千与琥珀 问题不再出现,没法更新了_(:з」∠)_