各种Perl脚本（服务器端包含）正在网站上调用具有许多功能的Perl模块。
编辑：
脚本使用use lib来引用文件夹中的库。
在繁忙时期，脚本（而非库）变成僵尸并使服务器超载。
服务器列出：
319 ? Z 0:00 [scriptname1.pl] <defunct>
320 ? Z 0:00 [scriptname2.pl] <defunct>
321 ? Z 0:00 [scriptname3.pl] <defunct>
我每个都有数百个实例。
编辑：
除了SSI指令外，我们不使用fork，system或exec
<!--#exec cgi="/cgi-bin/scriptname.pl"-->
据我所知，在这种情况下，httpd本身将是该进程的所有者。
MaxRequestPerChild设置为0，不应让父进程在子进程完成之前死亡。
到目前为止，我们发现暂时挂起某些脚本有助于服务器应对已失效的进程并防止其崩溃，但是毫无疑问，僵尸进程仍在形成。
显然gbacon似乎是最接近真理的，因为他的理论是服务器无法应对负载。
是什么导致httpd放弃这些过程？
有什么最佳实践可以防止这些情况发生？
谢谢
回答：
关键是罗布。
如他所说，生成SSI的CGI脚本将不处理那些SSI。对SSI的评估是在Apache 1.3请求周期中运行CGI之前进行的。这已在Apache 2.0及更高版本中修复，因此CGI可以生成SSI命令。
由于我们在Apache 1.3上运行，因此对于每个页面视图，SSI都将变为已失效的进程。尽管服务器试图清除它们，但正在运行的任务太忙而无法成功。结果，服务器跌倒了并且变得无响应。
作为短期解决方案，我们检查了所有SSI，并将某些过程移到了客户端，以释放服务器资源并给它一些时间进行清理。
后来我们升级到Apache 2.2。
最佳答案
我刚刚看到您的评论，说您正在运行Apache 1.3，并且可能与您的问题有关。
SSI可以运行CGI。但是生成SSI的CGI脚本将不处理那些SSI。对SSI的评估是在Apache 1.3请求周期中运行CGI之前进行的。这已在Apache 2.0及更高版本中修复，因此CGI可以生成SSI命令。
正如我上面建议的那样，请尝试自行运行脚本并查看输出。他们正在生成SSI吗？
编辑：您是否尝试过启动琐碎的Perl CGI脚本以仅打印出Hello World类型的HTTP响应？
然后，如果此方法有效，则添加一个简单的SSI指令，例如
<!--#printenv -->
看看会发生什么。
编辑2：刚意识到可能正在发生的事情。当子进程退出并且没有被收割时，就会发生僵尸。这些过程在过程表中徘徊，并慢慢消耗完资源。没有父进程的进程是孤立进程。
您是在Perl脚本中分叉进程吗？如果是这样，您是否向父级添加了一个waitpid（）调用？
您是否在脚本中也获得了正确的退出？
CORE::exit(0);