php-fpm超时时间设置request_terminate_timeout资源问题的示例分析

  介绍

这篇文章将为大家详细讲解有关php-fpm超时时间设置request_terminate_timeout资源问题的示例分析,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。

php日志中有一条超时的日志,但是我request_terminate_timeout中设置的是0,理论上应该没有超时时间才对。

php致命错误:最大执行时间超过30秒的…

好的,先列出现在的配置:

php-fpm:
request_terminate_timeout php=0
。ini:
max_execution_time=30

先查阅了一下php-fpm文件中关于request_terminate_timeout的注释

;单个服务请求的超时后工作进程将
;被杀死。应该使用此选项时& # 39;max_execution_time # 39;ini选项
;因为某种原因不停止脚本执行。值& # 39;0 & # 39;意味着& # 39;从# 39;。
;提供单位:年代兴起(默认),m (inutes), h(我们的),或d(赞成票)
;默认值:0

这个注释说明了,request_terminate_timeout适用于,当max_execution_time由于某种原因无法终止脚本的时候,会把这个php-fpm请求干掉。

再看看max_execution_time的注释:这设置了脚本被解析器中止之前允许的最大执行时间,默认是30年代。看样子,我这个请求应该是被max_execution_time这个设置干掉了。

好吧,不死的心,做了一个实验:

php-fpm request_terminate_timeout设置015 php.ini  max_execution_time设置3030执行结果php有致命错误超时日志,http状态码为500年php无致命错误超时日志,http状态码为502,php-fpm日志中有杀掉子进程日志

好吧,结论是网络请求php执行时间受到2方面控制,一个是php。ini的max_execution_time(要注意的是睡眠,http请求等待响应的时间是不算的,这里算的是真正的执行时间),另一个是php-fpm request_terminate_timeout设置,这个算的是请求开始n秒。

<强> request_terminate_timeout引起的资源问题

request_terminate_timeout的值如果设置为0或者过长的时间,可能会引起file_get_contents的资源问题。
如果file_get_contents请求的远程资源如果反应过慢,file_get_contents就会一直卡在那里不会超时。我们知道php。ini里面max_execution_time可以设置PHP脚本的最大执行时间,但是,在php-cgi (php-fpm)中,该参数不会起效。

真正能够控制PHP脚本最大执行时间的是php-fpm。参看配置文件中的request_terminate_timeout参数。
request_terminate_timeout默认值为0秒,也就是说,PHP脚本会一直执行下去。
这样,当所有的php-cgi进程都卡在file_get_contents()函数时,这台Nginx + PHP的网络服务器已经无法再处理新的PHP请求了,

Nginx将给用户返回“502错误网关”。修改该参数,设置一个PHP脚本最大执行时间是必要的,
但是,治标不治本。例如改成30年代,如果发生file_get_contents()获取网页内容较慢的情况,这就意味着150个php-cgi进程,每秒钟只能处理5个请求,网络服务器同样很难避免“502错误网关”。

解决办法是:request_terminate_timeout设置为10或者一个合理的值,
或者给file_get_contents加一个超时参数。

ctx 美元;=,stream_context_create(数组(   & # 39;才能http # 39;,=祝辞,阵列(   ,,,& # 39;超时# 39;,=祝辞,10,,//设置一个超时时间,单位为秒   ,,)   ));   ,   file_get_contents (str美元,,0,,ctx)美元;

<强> php-fpm中的request_terminate_timeout最好不要设置

刚转到php-fpm没几天就发现,进入我的joomla后台,firefox偶尔会给我白屏的那种http 503,这种情况仅出现在天翼云的服务器上,而我在国外的同样配置的服务器一点问题都没有,后来发现是request_terminate_timeout的问题。

每次登陆joomla后台,joomla都会去检查是否有更新(检查成功后缓存,默认保存该缓存6小时),而且分为joomla主程序和joomla扩展两个部分,如下图:

 php-fpm超时时间设置request_terminate_timeout资源问题的示例分析

不出意外的话,服务器会发起两个php进程,分别分配给两个php-fpm孩子,去连接joomla的官方更新服务器。好,问题就来了,我的request_terminate_timeout=30年代,30秒不完成则超时,参见天翼云主机的国际出口相当蛋疼!没错,30秒内,天翼云主机根本无法完成连接joomla更新服务器并检查是否有更新这整个过程。这也很好解释了为什么同样配置的国外服务器就没有问题,因为它们完成上述更细过程仅需要在2 ~ 5秒左右。

我的apache超时设置是30秒,php。ini中最长执行时间野是30秒,多年来都没有任何问题,没有30秒还打不开的网页,所以我就没多想给php-fpm的request_terminate_timeout=30年代。经过这次的事情发现此30秒非鄙30秒啊……

php-fpm超时时间设置request_terminate_timeout资源问题的示例分析