记一次莫名其妙的网站失去响应排查。之前网站一直是使用nginx做代理后端的apache运行php来提供服务。apache经常会不定期不定时间的出现不能服务失去响应,然后nginx出现"504 Gateway Time-out"
查看错误日志也看不到任何东西,以为是apache的bug(其实不是,下面会说原因)。
也许年龄大了人就不爱折腾,愿意保持原状不动,使用监控工具,每次收到报警后都重新启动apache勉强维持着。终于有一天我烦了,不就是处理php吗,我不用apache总行了吧,一怒之下使用源安装php-fpm转移到php-fpm来运行php。安装php并不麻烦,使用源安装还是很顺利的,唯一需要做的就是设置php worker工作进程的日志输出php错误日志。
一切准备就绪后把原来的proxy_pass换成fastcgipass就可以了。
代码如下:
upstream apachephp {
server www.Vevb.com:8080; #Apache1
}
....
proxy_pass http://apachephp;
替换成成
代码如下:
upstream php {
server 127.0.0.1:9000;
}
...
fastcgi_pass php;
就可以把apache上跑的php迁移到php-fpm上来跑。
原以为这样就可以高枕无忧了,迁移完成是也确实没什么问题,但是如果你不去分析问题的根本原因在哪。问题还是会找上门来,第二天nginx又报了504的gateway timeout。这回没apache什么事了吧,apache总算撇清了关系。
那应该还是在nginx和php-fpm身上,查看nginx的错误日志,可以看到
代码如下:
[error] 6695#0: *168438 upstream timed out (110: Connection timed out) while reading response header from upstream,
...
request: "GET /kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.Vevb.com"
看到这里基本上就排除了nginx嫌疑,nginx是在等待php处理"GET /kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1"超时退出了。
马上重启php-fpm,问题没有了,网站可以访问了。
再次访问该页面,依然没有响应,但同时访问别的页面正常,该页面刷新几次后,整个网站都是bad gateway timeout了。
问题就缩小到这个php脚本上了。
代码如下:
netstat -napo |grep "php5-fpm" | wc -l
查看php工作进程已经达到了配置文件里的上限10,有种感觉就是大家都被open.php这个脚本卡住了。
这个脚本是干什么的呢?这个脚本就是采集快递信息的,里面用到了php_curl。
PHP脚本如果执行时间超过php.ini中的配置项max_execution_time不出结果就会强制退出。
查看了php.ini中max_execution_time确实配了,值为30。
万能google派上用场了,经过不断google后得到下面这句话
set_time_limit()函数和配置指令max_execution_time只影响脚本本身执行的时间。任何发生在诸如使用system()的系统调用,流操作,数据库操作等的脚本执行的最大时间不包括其中,当该脚本已运行。
新闻热点
疑难解答