时间：2021-05-09 07:44:20 | 栏目：Nginx | 点击：次
记一次莫名其妙的网站失去响应排查。之前网站一直是使用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就可以了。
....
proxy_pass http://apachephp;
...
fastcgi_pass php;
那应该还是在nginx和php-fpm身上，查看nginx的错误日志，可以看到
马上重启php-fpm，问题没有了，网站可以访问了。
再次访问该页面，依然没有响应，但同时访问别的页面正常，该页面刷新几次后，整个网站都是bad gateway timeout了。
问题就缩小到这个php脚本上了。
查看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()的系统调用，流操作，数据库操作等的脚本执行的最大时间不包括其中，当该脚本已运行。
就是说如果脚本中执行了其它操作的时间是不计在脚本运行时间当中的，如果你没设置超时，那么php就会一直等待调用的结果。
查看open.php源文件一看，果然没有设置curl的超时时间。
增加如下两行,重新刷新，后问题解决了。
当然，除了这种方法外，php-fpm里也提供参数供我们强制杀死长时间无结果的进程，只是该参数默认没打开。
php-fpm的配置文件里可以设置一个参数request_terminate_timeout，请求终止的超时时间，当请求执行超过这个时间就会被kill。
同时它还有个参数request_slowlog_timeout，用来记录慢请求日志的。
命令行运行php的话，可以使用这段代码
if (pcntl_fork())
{
// some long time code which should be
// terminated after $real_execution_time_limit seconds passed if it's not
// finished by that time
}
else
{
sleep($real_execution_time_limit);
posix_kill(posix_getppid(), SIGKILL);
}