一，Apache三種MPM介紹
Apache 2.X 支持插入式並行處理模塊，稱爲多路處理模塊（MPM）。在編譯apache時必須選擇也只能選擇一個MPM，對類UNIX系統，有幾個不同的MPM可供選擇，它們會影響到apache的速度和可伸縮性。這三種MPM記錄於conf/extra/httpd-mpm.conf文件中。
Prefork MPM：這個多路處理模塊(MPM)實現了一個非線程型的、預派生的web服務器，它的工作方式類似於Apache 1.3。它適合於沒有線程安全庫，需要避免線程兼容性問題的系統。它是要求將每個請求相互獨立的情況下最好的MPM，這樣若一個請求出現問題就不會影響到其他請求。
這個MPM具有很強的自我調節能力，只需要很少的配置指令調整。最重要的是將MaxClients設置爲一個足夠大的數值以處理潛在的請求高峯，同時又不能太大，以致需要使用的內存超出物理內存的大小。
Worker MPM：此多路處理模塊(MPM)使網絡服務器支持混合的多線程多進程。由於使用線程來處理請求，所以可以處理海量請求，而系統資源的開銷小於基於進程的MPM。但是，它也使用了多進程，每個進程又有多個線程，以獲得基於進程的MPM的穩定性。
每個進程可以擁有的線程數量是固定的。服務器會根據負載情況增加或減少進程數量。一個單獨的控制進程(父進程)負責子進程的建立。每個子進程可以建立ThreadsPerChild數量的服務線程和一個監聽線程，該監聽線程監聽接入請求並將其傳遞給服務線程處理和應答。
不管是Worker模式或是Prefork 模式，Apache總是試圖保持一些備用的(spare)或者是空閒的子進程（空閒的服務線程池）用於迎接即將到來的請求。這樣客戶端就不需要在得到服務前等候子進程的產生。
Event MPM：以上兩種穩定的MPM方式在非常繁忙的服務器應用下都有些不足。儘管HTTP的Keepalive方式能減少TCP連接數量和網絡負載，但是 Keepalive需要和服務進程或者線程綁定，這就導致一個繁忙的服務器會耗光所有的線程。 Event MPM是解決這個問題的一種新模型，它把服務進程從連接中分離出來。在服務器處理速度很快，同時具有非常高的點擊率時，可用的線程數量就是關鍵的資源限 制，此時Event MPM方式是最有效的。一個以Worker MPM方式工作的繁忙服務器能夠承受每秒好幾萬次的訪問量（例如在大型新聞服務站點的高峯時），而Event MPM可以用來處理更高負載。值得注意的是，Event MPM不能在安全HTTP（HTTPS）訪問下工作。
二，配置三種MPM
查看Apache安裝的MPM
$ apachectl -l Compiled in modules: core.c prefork.c http_core.c mod_so.c
如果你看到perfork.c則表示當前爲perfork MPM模式。worker.c則表示爲worker MPM模式。event.c則表示爲event MPM模式。
Prefork 是UNIX平臺上默認的MPM，它所採用的預派生子進程方式也是apache 1.3中採用的模式。prefork 本身並沒有使用到線程，2.0 版本使用它是爲了與1.3版保持兼容性；另一方面，perfork用單獨的子進程來處理不同的請示，之進程之間是彼此獨立的，這也使其成爲最穩定的MPM之一。
配置Apache的MPM
需要的apache 配置安裝的時候需要指定模式：
$ ./configure --prefix=/usr/local/apache2worker --enable-so --with-mpm=worker $ make $ make install
配置Event MPM
同我上面的方法一樣，只需要在安裝的時候加上以下參數： –enable-nonportable-atomics=yes
需要注意的是Event MPM對於老的CPU可能是不支持的。
三，三種MPM參數分析
3.1 perfork MPM分析
mpm_prefork_module> StartServers 5 #數量的服務器進程開始 MinSpareServers 5 #最小數量的服務器進程，保存備用 MaxSpareServers 10 #最大數量的服務器進程,保存備用 MaxRequestWorkers 250 #最大數量的服務器進程允許開始 MaxConnectionsPerChild 0 #每個服務器進程的最大連接數
prefork控制進程在最初建立“StartServers”個子進程後，爲了滿足MinSpareServers設置的需要創建一個進程，等待一秒鐘，繼續創建兩 個，再等待一秒鐘，繼續創建四個……如此按指數級增加創建的進程數，最多達到每秒32個，直到滿足MinSpareServers設置的值爲止。這種模式 可以不必在請求到來時再產生新的進程，從而減小了系統開銷以增加性能。MaxSpareServers設置了最大的空閒進程數，如果空閒進程數大於這個值，Apache會自動kill掉一些多餘進程。這個值不要設得過大，但如果設的值比MinSpareServers小，Apache會自動把其調整爲 MinSpareServers+1。如果站點負載較大，可考慮同時加大MinSpareServers和MaxSpareServers。
MaxRequestsPerChild設置的是每個子進程可處理的請求數。每個子進程在處理了“MaxRequestsPerChild”個請求後將自動銷燬。0意味着無限，即子進程永不銷燬。雖然缺省設爲0可以使每個子進程處理更多的請求，但如果設成非零值也有兩點重要的好處：1、可防止意外的內存泄 漏。2、在服務器負載下降的時侯會自動減少子進程數。因此，可根據服務器的負載來調整這個值。
MaxRequestWorkers指令集同時將服務請求的數量上的限制。任何連接嘗試在MaxRequestWorkerslimit將通常被排隊，最多若干基於上ListenBacklog指令。在apache2.3.13以前的版本MaxRequestWorkers被稱爲MaxClients。
MaxRequestWorkers是這些指令中最爲重要的一個，設定的是 Apache可以同時處理的請求，是對Apache性能影響最大的參數。其缺省值150是遠遠不夠的，如果請求總數已達到這個值（可通過ps -ef|grep http|wc -l來確認），那麼後面的請求就要排隊，直到某個已處理請求完畢。這就是系統資源還剩下很多而HTTP訪問卻很慢的主要原因。雖然理論上這個值越大，可以處理的請求就越多，但Apache默認的限制不能大於256。
3.2 worker MPM分析
mpm_worker_module> StartServers 3 #初始數量的服務器進程開始 MinSpareThreads 75 #最小數量的工作線程，保存備用 MaxSpareThreads 250 #最大數量的工作線程，保存備用 ThreadsPerChild 25 #固定數量的工作線程在每個服務器進程 MaxRequestWorkers 400 #最大數量的工作線程 MaxConnectionsPerChild 0 #每個服務器進程的最大連接數
Worker由主控制進程生成“StartServers”個子進程，每個子進程中包含固定的ThreadsPerChild線程數，各個線程獨立地處理請求。同樣， 爲了不在請求到來時再生成線程，MinSpareThreads和MaxSpareThreads設置了最少和最多的空閒線程數；
而MaxRequestWorkers設置了同時連入的clients最大總數。如果現有子進程中的線程總數不能滿足負載，控制進程將派生新的子進程。
例如：5 StartServers x 25 ThreadsPerChild = 125 MaxRequestWorkers。
MinSpareThreads和MaxSpareThreads的最大缺省值分別是75和250。這兩個參數對Apache的性能影響並不大，可以按照實際情況相應調節 。
ThreadsPerChild是worker MPM中與性能相關最密切的指令。ThreadsPerChild的最大缺省值是64，如果負載較大，64也是不夠的。這時要顯式使用 ThreadLimit指令，它的最大缺省值是20000。
Worker模式下所能同時處理的請求總數是由子進程（StartServers）乘以ThreadsPerChild值決定的，應該大於等於MaxRequestWorkers。如果負載很大，現有的子進程數不能滿足時，控制進程會派生新的子進程。默認最大的子進程總數是16，加大時也需要顯式聲明ServerLimit（最大值是20000）。需要注意的是，如果顯式聲明瞭ServerLimit，那麼它乘以 ThreadsPerChild的值必須大於等於MaxRequestWorkers，而且MaxRequestWorkers必須是ThreadsPerChild的整數倍，否則 Apache將會自動調節到一個相應值。
3.3 event MPM分析
mpm_event_module> StartServers 3 #初始數量的服務器進程開始 MinSpareThreads 75 #最小數量的工作線程，保存備用 MaxSpareThreads 250 #最大數量的工作線程，保存備用 ThreadsPerChild 25 #固定數量的工作線程在每個服務器進程 MaxRequestWorkers 400 #最大數量的工作線程 MaxConnectionsPerChild 0 #每個服務器進程的最大連接數 ···················································································································································································· apache工作模式梳理 apache目前主要有兩種模式：prefork模式和worker模式： 1）prefork模式（默認模式） prefork是Unix平臺上的默認（缺省）MPM，使用多個子進程，每個子進程只有一個線程。每個進程在某個確定的時間只能維持一個連接，效率高，但內存佔用量比較大。 這個多路處理模塊(MPM)實現了一個非線程型的、預派生的web服務器，它的工作方式類似於Apache 1.3。它適合於沒有線程安全庫，需要避免線程兼容性問題的系統。它是要求將每個請求相互獨立的情況下最好的MPM，這樣若一個請求出現問題就不會影響到其他請求。 2）worker模式 worker使用多個子進程，每個子進程有多個線程，每個線程在某個確定的時間只能維持一個連接，內存佔用量比較小，適合高流量的http服務器。缺點是假如一個線程崩潰，整個進程就會連同其任何線程一起”死掉”，所以要保證一個程式在運行時必須被系統識別爲”每個線程都是安全的”。此多路處理模塊(MPM)使網絡服務器支持混合的多線程多進程。由於使用線程來處理請求，所以可以處理海量請求，而系統資源的開銷小於基於進程的MPM。但是它也使用了多進程，每個進程又有多個線程，以獲得基於進程的MPM的穩定性。 apache模式的查看和安裝 1.常看當前模式 如果apache已經安裝，我們可以用"httpd -l"命令查看當前模式。若找到prefork.c則表示當前工作在prefork模式;同理出現worker.c則工作在worker模式。 如果apache還未安裝，我們在編譯安裝的時候可以加入 --with-pem=(prefork|worker) 選項決定啓用什麼模式。 [root@master-node ~]# httpd -l Compiled in modules: core.c prefork.c //說明當前是prefork模式 http_core.c mod_so.c 2.切換模式 1）將當前的prefork模式啓動文件改名 [root@master-node ~]# which httpd /usr/sbin/httpd [root@master-node ~]# mv /usr/sbin/httpd /usr/sbin/httpd.prefork 2）將worker模式的啓動文件改名 [root@master-node ~]# mv /usr/sbin/httpd.worker /usr/sbin/httpd [root@master-node ~]# httpd -l Compiled in modules: core.c worker.c //說明已經切換成worker模式了 http_core.c mod_so.c 3）修改Apache配置文件 [root@master-node ~]# vim /usr/local/apache2/conf/extra/httpd-mpm.conf 找到裏邊的如下一段，可適當修改負載等參數： <IfModule mpm_worker_module>StartServers 2MaxClients 150MinSpareThreads 25MaxSpareThreads 75ThreadsPerChild 2 4）重新啓動服務 [root@master-node ~]# /usr/local/apache2/bin/apachectl restart 處於穩定性和安全性考慮，不建議更換apache2的運行方式，使用系統默認prefork即可。另外很多php模塊不能工作在worker模式下，例如redhat linux自帶的php也不能支持線程安全。所以最好不要切換工作模式。 prefork和worker模式的比較 prefork模式使用多個子進程，每個子進程只有一個線程。每個進程在某個確定的時間只能維持一個連接。在大多數平臺上，Prefork MPM在效率上要比Worker MPM要高，但是內存使用大得多。prefork的無線程設計在某些情況下將比worker更有優勢：它可以使用那些沒有處理好線程安全的第三方模塊，並且對於那些線程調試困難的平臺而言，它也更容易調試一些。 worker模式使用多個子進程，每個子進程有多個線程。每個線程在某個確定的時間只能維持一個連接。通常來說，在一個高流量的HTTP服務器上，Worker MPM是個比較好的選擇，因爲Worker MPM的內存使用比Prefork MPM要低得多。但worker MPM也由不完善的地方，如果一個線程崩潰，整個進程就會連同其所有線程一起"死掉"。由於線程共享內存空間，所以一個程序在運行時必須被系統識別爲"每個線程都是安全的"。 總的來說，prefork方式速度要稍高於worker，然而它需要的cpu和memory資源也稍多於woker。 prefork模式配置詳解 [root@master-node ~]# vim /usr/local/apache2/conf/extra/httpd-mpm.conf 找到下面的內容 <IfModule mpm_prefork_module>ServerLimit 256StartServers 5MinSpareServers 5MaxSpareServers 10MaxClients 256MaxR 1）ServerLimit 默認的MaxClient最大是256個線程，如果想設置更大的值，就的加上ServerLimit這個參數。20000是ServerLimit這個參數的最大值。如果需要更大，則必須編譯apache，此前都是不需要重新編譯Apache。 生效前提：必須放在其他指令的前面 2）StartServers 指定服務器啓動時建立的子進程數量，prefork默認爲5。 3）MinSpareServers 指定空閒子進程的最小數量，默認爲5。如果當前空閒子進程數少於MinSpareServers ，那麼Apache將以最大每秒一個的速度產生新的子進程。此參數不要設的太大。 4）MaxSpareServers 設置空閒子進程的最大數量，默認爲10。如果當前有超過MaxSpareServers數量的空閒子進程，那麼父進程將殺死多餘的子進程。此參數不要設的太大。如果你將該指令的值設置爲比MinSpareServers小，Apache將會自動將其修改成"MinSpareServers+1"。 5）MaxClients 限定同一時間客戶端最大接入請求的數量(單個進程併發線程數)，默認爲256。任何超過MaxClients限制的請求都將進入等候隊列，一旦一個鏈接被釋放，隊列中的請求將得到服務。要增大這個值，你必須同時增大ServerLimit。 6）MaxRequestsPerChild 每個子進程在其生存期內允許伺服的最大請求數量，默認爲10000.到達MaxRequestsPerChild的限制後，子進程將會結束。如果 MaxRequestsPerChild爲"0"，子進程將永遠不會結束。將MaxRequestsPerChild設置成非零值有兩個好處： 1--可以防止(偶然的)內存泄漏無限進行，從而耗盡內存。 2--給進程一個有限壽命，從而有助於當服務器負載減輕的時候減少活動進程的數量。 worker模式配置詳解 [root@master-node ~]# vim /usr/local/apache2/conf/extra/httpd-mpm.conf 找到下面的內容 <IfModule mpm_worker_module>StartServers 2MaxClients 150MinSpareThreads 25MaxSpareThreads 75ThreadsPerChild 25MaxRequestsPerChild 0</IfModule> 1）StartServers 服務器啓動時建立的子進程數，默認值是"3"。 2）MaxClients 允許同時伺服的最大接入請求數量(最大線程數量)。任何超過MaxClients限制的請求都將進入等候隊列。默認值 是"400"，16(ServerLimit)乘以25(ThreadsPerChild)的結果。因此要增加MaxClients的時候，你必須同時增加ServerLimit的值。 3）MinSpareThreads 最小空閒線程數，默認值是"75"。這個MPM將基於整個服務器監視空閒線程數。如果服務器中總的空閒線程數太少，子進程將產生新的空閒線程。 4）MaxSpareThreads 設置最大空閒線程數。默認值是"250"。這個MPM將基於整個服務器監視空閒線程數。如果服務器中總的空閒線程數太多，子進程將殺死多餘的空閒線程。 MaxSpareThreads的取值範圍是有限制的。Apache將按照如下限制自動修正你設置的值：worker要求其大於等於 MinSpareThreads加上ThreadsPerChild的和。 5）ThreadsPerChild 每個子進程建立的常駐的執行線程數。默認值是25。子進程在啓動時建立這些線程後就不再建立新的線程了。 6）MaxRequestWorkers = MaxClients 最大連接數 7）MaxRequestsPerChild 設置每個子進程在其生存期內允許伺服的最大請求數量。到達MaxRequestsPerChild的限制後，子進程將會結束。如果MaxRequestsPerChild爲"0"，子進程將永遠不會結束。將MaxRequestsPerChild設置成非零值有兩個好處： 1--可以防止(偶然的)內存泄漏無限進行，從而耗盡內存。 2--給進程一個有限壽命，從而有助於當服務器負載減輕的時候減少活動進程的數量。 注意對於KeepAlive鏈接，只有第一個請求會被計數。事實上，它改變了每個子進程限制最大鏈接數量的行爲。 總結 以前apache主流模式爲prefork，現在worker模式也開始多了起來，區別來說，worker模式可以應對高流量，但是安全性不太好;prefork模式安全性比較好，但是性能會差一點，各位可以根據自己服務器的類別選取不同的模式，更好的使用apache。