我们遇到的问题是Apache（2.4.10）FCGID（2.3.9）PHP进程陷入Debian的“工作”状态。
这些PHP进程不占用系统资源（超出以前使用的内存占用空间来处理先前的请求）并且处于空闲状态。 它们仍然附加到正确的逻辑父进程（apache2进程处理此vhost上的请求）
将strace连接到它们会显示它们处于以下状态： 接受（0， 我们假设听取了下一个请求。
我们在handle_shutdown函数中的PHP处理中添加的应用程序日志记录显示所有这些请求都已经达到了handle_shutdown函数（没有错误） - 正如您对任何PHP处理的请求所期望的那样（因为您总是点击handle_shutdown函数），所以据我们所知，整个请求已“成功” 在apache访问日志中记录200响应。
但是，apachectl fullstatus fcgid部分显示的过程是“工作”而不是“就绪”
更改Fcgid设置上的回收因子（最大请求数，生命周期数，超时设置数或更高等等）似乎不会影响这些事件发生的规律性。
apachectl graceful成功清理所有空闲“工作”线程并恢复正常。
然而，当然，如果我们在没有观察的情况下离开这个，最终，每个进程迟早会以这种状态结束，直到我们最终得到一个完全空闲的服务器，其中我们所有的最大进程（100）都是陷入“等待”但闲置。此时内存使用是合理的，当然CPU，网络等也可以忽略不计，因为服务器响应的唯一请求是fullstatus（因为它没有点击PHP vhost部分）
答案 0 :(得分：0)
好。
事实证明，第一个建议的响应（将apache2 Mutex模式设置为＆＃34; sem＆＃34;来自文件：＆＃34;是正确的，但是当它第一次应用时 - 我们的apache2服务并没有冷启动但重新启动，所以当然没有实际使用新的Mutex模式。
因此，当测试仍显示错误时，此建议已被注销。
发生了什么？
apache2 fcgid PM进程保留了所有当前子进程的三个列表：＆＃34; Ready＆＃34;，＆＃34; Working＆＃34;和＆＃34;错误/退出＆＃34;。
它使用互斥锁（锁）来保护这些列表，只要它移动子进程＆＃39;信息块来自＆＃34; Ready＆＃34;到＆＃34;等待＆＃34;当它给它一个处理请求时 - 再次当子进程完成请求时，为了将它移回＆＃34; Ready＆＃34;。
此互斥锁保护从多个线程或进程访问的共享资源不会被过度打开＆＃34;通过一个进程，而另一个进程也试图读取或写入一个值（导致其他进程读取不一致的值，或者使其写入丢失），只允许一次一个进程访问该重要资源。
默认＆＃34;文件：＆＃34; Debian上的互斥体似乎不能很好地导致工作（正如其他网络上所建议的那样），同时发生了两次状态变化请求，因此一次更改成功，而另一次（并发）更改获得＆＃34;丢失＆＃34 ;.
因此，孩子知道它已经完成但父母认为它没有。
哎呀！
道德：在Debian上，如果将apache2与fcgid一起使用，请更改你的互斥模式 - 并确保你完成apache停止，然后启动apache，并且不要信任那些只重启apache的服务器管理员！