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为何进程会自杀失败？查了许多资料无果=_=于是本文待更新，如果找到了解决方案会直接更新本文。