关于 apache 的 prefork

http://blog.csdn.net/marcolu/archive/2004/08/02/59085.aspx

常用的应该就只有3个：worker|prefork|perchild

   1. prefork：在功能上就是使用 Apache的运行方式，一个父进程，然后根据设置以及连接情况生成相应的子进程数。这种模式可靠性和健壮性都是最好的。但是在性能上，开销过大。达不到我们这些“吸血鬼”的要求了^_^。如果连接数过多的话，会导致我们无法远程登陆，一定要等到连接数下降后才能连接，这也是最让我头痛的事情。
   2. worker：混合线程/进程的MPM。一个父进程，后面是带有线程的子进程。每个子进程的线程数是固定且相同的。这是最“平庸”的一个模式，但也是使用人最多的一种模式。因为它性能等各方面比较均衡。性能上要比prefork好一些，只是牺牲了一点点的健壮性和可靠性而已。一般推荐使用这个选项。
   3. perchild：也是混合线程/进程的MPM。当启动perchild MPM时，它会建立指定数量的子进程，且每个子进程都具有指定数量的线程，如负载增加了，那它不会建立新的进程（子进程是固定的），只是在子进程下建立新的线程。它还有一个特点就是可以为每一个子进程配置不同的用户和组。也可以为每个虚拟主机指定一个子进程。这种模式性能是最佳的，但是可靠性和健壮性就相对是最差的。各取所需，我个人觉得这种模式也不错，如果你不用第三方的模块的话^_^。

http://blog.csdn.net/tingya/archive/2006/08/09/1040799.aspx
http://blog.csdn.net/tingya/archive/2006/08/28/1133825.aspx
http://blog.csdn.net/tingya/archive/2006/08/28/1133836.aspx
Apache中预创建Preforking MPM 机制剖析

http://ldgliguang.blog.163.com/blog/static/81845820074101133992/
在这里看到这样的描述：
将MaxRequestsPerChild设置成非零值有两个好处：
1.可以防止(偶然的)内存泄漏无限进行，从而耗尽内存。
2.给进程一个有限寿命，从而有助于当服务器负载减轻的时候减少活动进程的数量。

http://blog.codingnow.com/2007/05/good_design.html
又在这里看到，《Unix痛恨者手册》上有一句话。
“通过控制进程的产生与终止来进行内存管理，这就如同通过控制人的生死来对付疾病”


预先派生模型有一些优点，例如健壮性以及可靠性。如果子进程异常退出，那么服务器就会丢失一个连接，而且仅仅丢失一个连接。服务器的其余部分还将继续运行，并且可以为请求提供服务。唯一可以注意到问题出现的用户就是不幸地进行了导致问题地请求的用户。

不过预派生模型也有自己的缺点，比如扩充性。

这种设计的最后问题就是它会消弱某些优化。因为每个请求都会在它自己的进程中运行，所以进程之间很难共享任何信息。

http://archive.netbsd.se/?ml=apache-httpd-dev&a=2004-02&t=44730

hmmm, looks like the httpd parent is trying to shut down a child process gracefully after a decrease in traffic.
write(6, "!", 1) means it's using the pipe of death.  Since waitpid() is returning 0, it looks the child processes aren't responding to the pipe of death.  Could it be that network traffic is totally dried up during these periods? or could the child processes be in the middle of some long running request?

Could it be that network traffic is totally dried up during these periods? or could the child processes be in the middle of some long running request?

从这两句来看，似乎 parent write(6, "!", 1) 之后， child 需要等到有一个请求之后才会知道这个消息。child 在 idle 的时候，应该处在：

accept_mutex_on();
accept();
accept_mutex_off();

被阻塞在 accept ，这个时候尽管 parent 写 pod ，但是不能把 child 从 accept 中唤醒过来。

http://www.webmonkey.com/webmonkey/97/49/index3a_page4.html?tw=backend

This effectively locks those children into serving requests from that one socket and no other sockets, and they'll be stuck there until enough new requests appear on that socket to wake them all up.