如果你在webmin面板的apache错误日志里看到mod_fcgid: read data timeout in 31 seconds,那么八成是php执行时间太短导致的,我们通常会加大php参数max_execution_time(设置方法: 如何修改上传文件的大小限制?怎么修改phpmyadmin上传数据库大小限制?)但是,我们可能还是在上传大文件的时候,发现执行时间timeout错误,怎么回事?经过研究,我们发现webmin还有一个php程序的执行时间的参数需要修改,这就是IPCCommTimeout,如何修改IPCCommTimeout?请看下图:
点击编辑指令,找到IPCCommTimeout,默认是31,改成351试一试,然后保存,重启apache
提示:上述设置重启apache后,如果测试还有类似错误,可以在apache配置文件的最底部,直接加上 IPCCommTimeout 633 然后重启apache在试一试。
IPCCommTimeout参数原理分析范例:
webmin的PHP将使用FastCGI模块来加载,也就是mod_fcgid。
不过最近遇到一个头疼的问题,就是访问一些执行时间较长的PHP程序的时候,服务器会返回500错误。将PHP的错误输出功能打开,在500错误之前未见到任何错误信息输出。检查Apache的日志文件也没有发现PHP报错。
如此反复的检查了几次后,对PHP文件权限和目录权限进行了调整,也检查了php程序没有问题(之前都一直正常的)。怪事了,难道这500错误解决不了了吗?肯定还有什么原因!
于是,仔细再查阅了apache的错误日志,发现了一行提示:
[warn] mod_fcgid: read data timeout in 40 seconds
这个说明fcgid模块在读取数据的时候超时了。经过多次测试,证明500错误的时候会产生这条记录,看来罪魁祸首就是这个模块了。立马输入命令:
#vim /etc/apache2/mods-available/fcgid.conf
打开后默认的情况如下(我在配置Apache Worker模式的时候,只将PHP解析修改过来了,别的参数都保持默认未动):
<IfModule mod_fcgid.c>
AddHandler fcgid-script .php .py .pl .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IPCConnectTimeout 20
</IfModule>
开始觉得IPCConnectTimeout 20的值太小了,于是调整到300,重启Apache后执行出错的php脚本文件,结果还是报500错误。上网仔细一查,这个模块下可用的参数还真不少。另外一个叫做“IPCCommTimeout”的参数吸引了我的注意力,这是FastCGI模块在与程序通讯的时候的超时时间。不管三七二十一,死马当活马医,将这个参数添加后,也设置为300,这样一来文件的内容就如下了:
<IfModule mod_fcgid.c>
AddHandler fcgid-script .php .py .pl .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IPCConnectTimeout 300
IPCCommTimeout 300
</IfModule>
再次重启apache,运行出错的php脚本测试,成功得到结果,没有再出现500错误,问题解决。为了不使FastCGI模块因为连接超时时间过长而占据服务器内存,又将IPCConnectTimeout参数恢复为默认的20。
总结一下,本次问题出现的关键就是,PHP脚本中需要与别的网址进行通讯,而可能中间时间读取过长导致超时。虽然php脚本中使用函数设置了脚本超时时间,php设置中超时的设置亦很长,不过FastCGI模块还是按照它自己的设置在工作着,导致40秒超时错误。经过参数的添加后,设置为300秒超时时间,足够脚本执行完毕了。
此外,FastCGI下面还有多个参数,常用的参数的意义如下:
IdleTimeout 发呆时限
ProcessLifeTime 一个进程的最长生命周期,过期之后无条件kill
MaxProcessCount 最大进程个数
DefaultMinClassProcessCount 每个程序启动的最小进程个数
DefaultMaxClassProcessCount 每个程序启动的最大进程个数
IPCConnectTimeout 程序响应超时时间
IPCCommTimeout 与程序通讯的最长时间,上面的超时错误就是这个值设置过小造成的
MaxRequestsPerProcess 每个进程最多完成处理个数,达成后自杀
留做备用,以后如果还有FastCGI的问题,再进行检查。