linux apache两种工作模式详解
apache兩種工作模式詳解
剛接觸這兩個配置時很迷糊,全部開啟或全部注釋沒有幾多變化。今天搜索到這么一篇講得還不錯的文章,看了幾篇,還是不能完全記住,做一個收藏。
空閑子進程:是指沒有正在處理請求的子進程。
1、prefork.c模塊(一個非線程型的、預派生的MPM)
??? prefork MPM 使用多個子進程,每個子進程只有一個線程。每個進程在某個確定的時間只能維持一個連接。在大多數平臺上,Prefork MPM在效率上要比Worker MPM要高,但是內存使用大得多。prefork的無線程設計在某些情況下將比worker更有優勢:他能夠使用那些沒有處理好線程安全的第三方模塊,并且對于那些線程調試困難的平臺而言,他也更容易調試一些。
ServerLimit?? 20000
StartServers?? 5
MinSpareServers?? 5
MaxSpareServers?? 10
MaxClients?? 1000
MaxRequestsPerChild 0
ServerLimit???? 2000
//默認的MaxClient最大是256個線程,假如想配置更大的值,就的加上ServerLimit這個參數。20000是ServerLimit這個參數的最大值。假如需要更大,則必須編譯apache,此前都是無需重新編譯Apache。
生效前提:必須放在其他指令的前面
StartServers?? 5
//指定服務器啟動時建立的子進程數量,prefork默認為5。
MinSpareServers?? 5
//指定空閑子進程的最小數量,默認為5。假如當前空閑子進程數少于MinSpareServers ,那么Apache將以最大每秒一個的速度產生新的子進程。此參數不要設的太大。
MaxSpareServers?? 10
// 配置空閑子進程的最大數量,默認為10。假如當前有超過MaxSpareServers數量 的空閑子進程,那么父進程將殺死多余的子進程。此參數不要設的太大。假如您將該指令的值配置為比MinSpareServers小,Apache將會自動將其修改成"MinSpareServers+1"。
MaxClients?? 256
//限定同一時間客戶端最大接入請求的數量(單個進程并發線程數),默認為256。任何超過MaxClients限制的請求都將進入等候隊列,一旦一個鏈接被釋放,隊列中的請求將得到服務。要增大這個值,您必須同時增大ServerLimit 。
MaxRequestsPerChild 10000
//每個子進程在其生存期內允許伺服的最大請求數量,默認為10000.到達MaxRequestsPerChild的限制后,子進程將會結束。假如MaxRequestsPerChild為"0",子進程將永遠不會結束。
將MaxRequestsPerChild配置成非零值有兩個好處:
1.能夠防止(偶然的)內存泄漏無限進行,從而耗盡內存。
2.給進程一個有限壽命,從而有助于當服務器負載減輕的時候減少活動進程的數量。
工作方式:
一個單獨的控制進程(父進程)負責產生子進程,這些子進程用于監聽請求并作出應答。Apache總是試圖保持一些備用的 (spare)或是空閑的子進程用于迎接即將到來的請求。這樣客戶端就無需在得到服務前等候子進程的產生。在Unix系統中,父進程通常以root身份運行以便邦定80端口,而 Apache產生的子進程通常以一個低特權的用戶運行。User和Group指令用于配置子進程的低特權用戶。運行子進程的用戶必須要對他所服務的內容有讀取的權限,但是對服務內容之外的其他資源必須擁有盡可能少的權限。
2、worker.c模塊(支持混合的多線程多進程的多路處理模塊)
??? worker MPM 使用多個子進程,每個子進程有多個線程。每個線程在某個確定的時間只能維持一個連接。通常來說,在一個高流量的HTTP服務器上,Worker MPM是個比較好的選擇,因為Worker MPM的內存使用比Prefork MPM要低得多。但worker MPM也由不完善的地方,假如一個線程崩潰,整個進程就會連同其任何線程一起"死掉".由于線程共享內存空間,所以一個程式在運行時必須被系統識別為"每個線程都是安全的"。
ServerLimit?? 50
ThreadLimit?? 200
StartServers?? 5
MaxClients?? 5000
MinSpareThreads?? 25
MaxSpareThreads?? 500
ThreadsPerChild?? 100
MaxRequestsPerChild 0
ServerLimit 16
//服務器允許配置的進程數上限。這個指令和ThreadLimit結合使用配置了MaxClients最大允許配置的數值。任何在重啟期間對這個指令的改變都將被忽略,但對MaxClients的修改卻會生效。
ThreadLimit 64
//每個子進程可配置的線程數上限。這個指令配置了每個子進程可配置的線程數ThreadsPerChild上限。任何在重啟期間對這個指令的改變都將被忽略,但對ThreadsPerChild的修改卻會生效。默認值是"64".
StartServers 3
//服務器啟動時建立的子進程數,默認值是"3"。
MinSpareThreads 75
//最小空閑線程數,默認值是"75"。這個MPM將基于整個服務器監控空閑線程數。假如服務器中總的空閑線程數太少,子進程將產生新的空閑線程。
MaxSpareThreads 250
// 配置最大空閑線程數。默認值是"250"。這個MPM將基于整個服務器監控空閑線程數。假如服 務器中總的空閑線程數太多,子進程將殺死多余的空閑線程。MaxSpareThreads的取值范圍是有限制的。Apache將按照如下限制自動修正您配置的值:worker需要其大于等于
MinSpareThreads加上ThreadsPerChild的和MaxClients 400
//允許同時伺服的最大接入請求數量(最大線程數量)。任何超過MaxClients限制的請求都將進入等候 隊列。默認值是"400",16 (ServerLimit)乘以25(ThreadsPerChild)的結果。因此要增加MaxClients的時候,您必須同時增加 ServerLimit的值。
ThreadsPerChild 25
//每個子進程建立的常駐的執行線程數。默認值是25。子進程在啟動時建立這些線程后就不再建立新的線程了。
MaxRequestsPerChild 0
//配置每個子進程在其生存期內允許伺服的最大請求數量。到達MaxRequestsPerChild的限制后,子進程將會結束。假如MaxRequestsPerChild為"0",子進程將永遠不會結束。
將MaxRequestsPerChild配置成非零值有兩個好處:
1.能夠防止(偶然的)內存泄漏無限進行,從而耗盡內存。
2.給進程一個有限壽命,從而有助于當服務器負載減輕的時候減少活動進程的數量。
注意
對于KeepAlive鏈接,只有第一個請求會被計數。事實上,他改變了每個子進程限制最大鏈接數量的行為。
工作方式:
每個進程能夠擁有的線程數量是固定的。服務器會根據負載情況增加或減少進程數量。一個單獨的控制進程(父進程)負責子進程的建立。每個子進程能夠建立ThreadsPerChild數量的服務線程和一個監聽線程,該監聽線程監聽接入請求并將其傳遞給服務線程處理和應答。Apache總是試圖維持一個備用(spare)或是空閑的服務線程池。這樣,客戶端無須等待新線程或新進程的建立即可得到處理。在Unix中,為了能夠綁定80端口,父進程一般都是以root身份啟動,隨后,Apache以較低權限的用戶建立子進程和線程。User和Group指令用于配置Apache子進程的權限。雖然子進程必須對其提供的內容擁有讀權限,但應該盡可能給予他較少的特權。另外,除非使用了suexec ,否則,這些指令配置的權限將被CGI腳本所繼承。
公式:
ThreadLimit >= ThreadsPerChild
MaxClients = MinSpareThreads+ThreadsPerChild
硬限制:
ServerLimi和ThreadLimit這兩個指令決定了活動子進程數量和每個子進程中線程數量的硬限制。要想改變這個硬限制必須完全停止服務器然后再啟動服務器(直接重啟是不行的)。
Apache在編譯ServerLimit時內部有一個硬性的限制,您不能超越這個限制。
prefork MPM最大為"ServerLimit 200000"
其他MPM(包括work MPM)最大為"ServerLimit 20000
Apache在編譯ThreadLimit時內部有一個硬性的限制,您不能超越這個限制。
mpm_winnt是"ThreadLimit 15000"
其他MPM(包括work prefork)為"ThreadLimit 20000
注意
使用ServerLimit和ThreadLimit時要特別當心。假如將ServerLimit和ThreadLimit配置成一個高出實際需要許多的值,將會有過多的共享內存被分配。當配置成超過系統的處理能力,Apache可能無法啟動,或系統將變得不穩定。
查看apache的并發請求數及其TCP連接狀態:
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
?
?
?
理解和優化apache并發控制參數prefork
一個apache有linux下的并發不是很高的,大約到3K的樣子(其實處理的http的請求可能只有300/s),普通的服務器都會不同程度的出現問題.apache有關并發控制主要是 prefork和worker二個其中一個來控制.我們可以使用httpd -l來確定當前使用的MPM是prefork.c,還是Worker.c.下面是apache中有關prefork的配置.下面是我優化過的參數.
<IfModule prefork.c>
#有這個參數就不必像apache1一樣修改源碼才能修改256客戶數的限制,聽講要放到最前面才會生效,2000是這個參數的最大值
ServerLimit 2000
#指定服務器啟動時建立的子進程數量,prefork默認為5。
StartServers 25
#指定空閑子進程的最小數量,默認為5。如果當前空閑子進程數少于MinSpareServers ,那么Apache將以最大每秒一個的速度產生新的子進程。此參數不要設的太大。
MinSpareServers 25
#設置空閑子進程的最大數量,默認為10。如果當前有超過MaxSpareServers數量的空閑子進程,那么父進程將殺死多余的子進程。此參數 不要設的太大。如果你將該指令的值設置為比MinSpareServers小,Apache將會自動將其修改成"MinSpareServers+1"。
MaxSpareServers 50
#限定同一時間客戶端最大接入請求的數量(單個進程并發線程數),默認為256。任何超過MaxClients限制的請求都將進入等候隊列,一旦一個鏈接被釋放,隊列中的請求將得到服務。要增大這個值,你必須同時增大ServerLimit 。
MaxClients 2000
#每個子進程在其生存期內允許伺服的最大請求數量,默認為10000.到達MaxRequestsPerChild的限制后,子進程將會結束。如果MaxRequestsPerChild為"0",子進程將永遠不會結束。
MaxRequestsPerChild 10000
</IfModule>
將MaxRequestsPerChild設置成非零值有兩個好處:
1.可以防止(偶然的)內存泄漏無限進行,從而耗盡內存。
2.給進程一個有限壽命,從而有助于當服務器負載減輕的時候減少活動進程的數量。
工作方式:
一個單獨的控制進程(父進程)負責產生子進程,這些子進程用于監聽請求并作出應答。Apache總是試圖保持一些備用的 (spare)或者是空閑的子進程用于迎接即將到來的請求。這樣客戶端就不需要在得到服務前等候子進程的產生。在Unix系統中,父進程通常以root身 份運行以便邦定80端口,而 Apache產生的子進程通常以一個低特權的用戶運行。User和Group指令用于設置子進程的低特權用戶。運行子進程的用戶必須要對它所服務的內容有 讀取的權限,但是對服務內容之外的其他資源必須擁有盡可能少的權限。
對上面的有些值,一定要記的不是越大越好.這個需要經過幾次嘗試和出錯之后才能選好要使用的值(不同的硬件處理水平不一樣)。最重要的值是maxclient允許足夠多的 工作進程,同時又不會導致服務器進行過度的交換(死機)。如果傳入的請求超出處理能力而讓服務器當掉的話,那么至少滿足此值的那些請求會得到服務,其他請求被阻塞這樣會更加好。
?
我們調優常常要查看httpd進程數(即prefork模式下Apache能夠處理的并發請求數):
#ps -ef | grep httpd | wc -l
出現的結果,就是當前Apache能夠處理的多少個并發請求,這個值Apache根據負載情況自動調.
查看Apache的并發請求數及其TCP連接狀態:
#netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
返回結果示例:
LAST_ACK 5
SYN_RECV 30
ESTABLISHED 1597
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057
其中的SYN_RECV表示正在等待處理的請求數;ESTABLISHED表示正常數據傳輸狀態;TIME_WAIT表示處理完畢,等待超時結束的請求數。
狀態:描述
CLOSED:無連接是活動的或正在進行
LISTEN:服務器在等待進入呼叫
SYN_RECV:一個連接請求已經到達,等待確認
SYN_SENT:應用已經開始,打開一個連接
ESTABLISHED:正常數據傳輸狀態
FIN_WAIT1:應用說它已經完成
FIN_WAIT2:另一邊已同意釋放
ITMED_WAIT:等待所有分組死掉
CLOSING:兩邊同時嘗試關閉
TIME_WAIT:另一邊已初始化一個釋放
LAST_ACK:等待所有分組死掉
可以使用Linux下的webbench來作壓力測試.
?
總結
以上是生活随笔為你收集整理的linux apache两种工作模式详解的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: BGP community
- 下一篇: nginx+fastcgi实现动静分离架