mod_fcgid:读取数据超时错误
我转到了一个使用fcgid的非托管服务器(在使用mod_php之前)，在错误日志中我看到了大量这样的错误：
4月23日21:17:12 2012 客户66.249.68.233 mod_fcgid:在31秒内读取数据超时4月23日21:17:12 2012 客户66.249.68.233脚本头的提前结束: index.php 4月23日17:59:51 2012 客户74.117.180.58 mod_fcgid:在31秒内读取数据超时4月23日17:59:51 2012 客户74.117.180.58连接超时: mod_fcgid: ap_pass_brigade在handle_request_ipc函数中失败
当负载较高时(2-3)，备份期间似乎会出现更多这样的情况，我甚至在备份期间运行tar / mysqldump时(30秒后用户看到500条错误消息)时，在负载为3的情况下复制了这种情况。服务器会超载吗？这个问题似乎是相关的如果下载中断+ Fcgid挂起，但不是相同的。
这是一个一流的服务器，我很惊讶这会是太多。下面是一些规范:带Webmin的6-7个Drupal站点
- 英特尔核心™i7-2600四核包括。超线程技术
- 16 GB DDR3 RAM
- 硬disks2 x 3 TB SATA 6 Gb/s HDD 7200 rpm (软件-RAID 1)
- NIC1 Gbit OnBoard以100 Mbit连接
回答 2
Server Fault用户
发布于 2012-04-23 15:32:09
这些错误意味着脚本运行时间超过31秒，因此它们被终止，正如您的fcgid.conf所说的那样。标准的超时时间是40秒。
您可以轻松地通过编写一个test.php来检查这种行为：
<?php sleep(32); ?>这将给出一个错误500，并将此错误放入日志中。
解决这个问题有两种可能性：
- 重新创建您的index.php (或后面的应用程序)并解决潜在的循环问题(脚本将永远运行并在31秒后终止)。
- 将超时设置得更高。这必须对每个vhost执行(不要忘记SSL!)，因为每次另一个vhost加载时都会更改此设置，并且将一直保持到生成的进程停止为止。最简单的方法是编辑
/etc/apache2/mods-available/fcgid.conf。这就是我们正在使用的：IdleTimeout 3600ProcessLifeTime 7200IPCConnectTimeout 8IPCCommTimeout 600BusyTimeout 300
编辑:哦，第二个错误与URL中过长的查询字符串有关。若要允许更长的查询字符串，还可以编辑fcgid.conf和插入
MaxRequestLen 15728640不要忘记重新启动apache来杀死所有正在运行的进程，这样他们就可以获得新的信任。
Server Fault用户
发布于 2012-04-23 16:10:29
默认情况下，mysqldump会在数据库运行时写入锁，以便在备份期间不会更改数据，这可能会导致损坏。Drupal会在每个请求上写入数据库，因此在mysqldump运行时请求将挂起，并最终超时。
如果您正在使用InnoDB (或者可以转换到它)，那么您可以使用Percona XtraBackup进行热备份。除此之外，不要将mysqldump输送到tar或gzip；转储.sql文件，然后在mysqldump完成(并释放锁)之后在其上运行tar/gzip。
还要注意，在fcgid的某些版本中，有一个错误导致了仅在虚拟主机块中应用设置，并全局应用上次读取块中的设置.。
https://serverfault.com/questions/382261
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号