php-FPM運行原理以及相關配置 一.PHP-FPM運行原理 CGI 是 Web Server 與后臺語言交互的協議,有了這個協議,開發者可以使用任何語言處理 Web Server 發來的請求,動態的生成內容。但 CGI 有一個致命的缺點,那就是每處理一個請求都需要 fork 一個全新的進程,隨著 Web 的興起,高并發越來越成為常態,這樣低效的方式明顯不能滿足需求。就這樣,FastCGI 誕生了,CGI 很快就退出了歷史的舞臺。FastCGI,顧名思義為更快的 CGI,它允許在一個進程內處理多個請求,而不是一個請求處理完畢就直接結束進程,性能上有了很大的提高 至于 FPM (FastCGI PRocess Manager),它是 FastCGI 的實現,任何實現了 FastCGI 協議的 Web Server 都能夠與之通信。FPM 之于標準的 FastCGI,也提供了一些增強功能,具體可以參考官方文檔:PHP: FPM Installation。 FPM 是一個 PHP 進程管理器,包含 master 進程和 worker 進程兩種進程:master 進程只有一個,負責監聽端口,接收來自 Web Server 的請求,而 worker 進程則一般有多個 (具體數量根據實際需要配置),每個進程內部都嵌入了一個 PHP 解釋器,是 PHP 代碼真正執行的地方 從 FPM 接收到請求,到處理完畢,其具體的流程如下:
FPM 的 master 進程接收到請求 master 進程根據配置指派特定的 worker 進程進行請求處理,如果沒有可用進程,返回錯誤,這也是我們配合 Nginx 遇到502錯誤比較多的原因。 worker 進程處理請求,如果超時,返回504錯誤 請求處理結束,返回結果 FPM 從接收到處理請求的流程就是這樣了,那么 Nginx 又是如何發送請求給 fpm 的呢?這就需要從 Nginx 層面來說明了。
我們知道,Nginx 不僅僅是一個 Web 服務器,也是一個功能強大的 Proxy 服務器,除了進行 http 請求的代理,也可以進行許多其他協議請求的代理,包括本文與 fpm 相關的 fastcgi 協議。為了能夠使 Nginx 理解 fastcgi 協議,Nginx 提供了 fastcgi 模塊來將 http 請求映射為對應的 fastcgi 請求。
Nginx 的 fastcgi 模塊提供了 fastcgi_param 指令來主要處理這些映射關系,下面 Ubuntu 下 Nginx 的一個配置文件,其主要完成的工作是將 Nginx 中的變量翻譯成 PHP 中能夠理解的變量
除此之外,非常重要的就是 fastcgi_pass 指令了,這個指令用于指定 fpm 進程監聽的地址,Nginx 會把所有的 php 請求翻譯成 fastcgi 請求之后再發送到這個地址
二.PHP-FPM進程管理 php-fpm進程管理配置為pm參數,可以設置為靜態(static)和動態(dynamic)兩種。 詳細的配置參數有: pm.max_children:靜態方式下開啟的php-fpm進程數量。 pm.start_servers:動態方式下的起始php-fpm進程數量。 pm.min_spare_servers:動態方式下的最小php-fpm進程數量。 pm.max_spare_servers:動態方式下的最大php-fpm進程數量
靜態(static) 進程數自始至終都是pm.max_children指定的數量,pm.start_servers,pm.min_spare_servers,pm.max_spare_servers配置將沒有作用。 對于內存比較吃緊,同時并發量不是很大的應用,可以考慮采用static的方式,這樣可以很好的控制php-fpm的所消耗的總內存數,讓系統更加 平穩運行。另外由于并發量很小,可以適當的把設置pm.max_requests小一些,以便讓php-fpm進程有機會重啟,從而釋放其占用的內存動態(dynamic) 進程數是動態的,最開始是pm.start_servers指定的數量,如果請求較多,則會自動增加,但不超過 pm.max_children指定的數量,同時保證空閑的進程數不小于pm.min_spare_servers,如果進程數較多,也會進行相應清理, 保證多余的進程數不多于pm.max_spare_servers。那么,對于我們的服務器,選擇哪種執行方式比較好呢?事實上,跟Apache一樣,運行的PHP程序在執行完成后,或多或少會有內存泄露的問題。這也是為什么開始的時候一個php-fpm進程只占用3M左右內存,運行一段時間后就會上升到20-30M的原因了。
對于內存大的服務器(比如8G以上)來說,指定靜態的max_children實際上更為妥當,因為這樣不需要進行額外的進程數目控制,會提高效率。因為頻繁開關php-fpm進程也會有時滯,所以內存夠大的情況下開靜態效果會更好。數量也可以根據 內存/30M 得到,比如8GB內存可以設置為100,那么php-fpm耗費的內存就能控制在 2G-3G的樣子。如果內存稍微小點,比如1G,那么指定靜態的進程數量更加有利于服務器的穩定。這樣可以保證php-fpm只獲取夠用的內存,將不多的內存分配給其他應用去使用,會使系統的運行更加暢通。
對于小內存的服務器來說,比如256M內存的VPS,即使按照一個20M的內存量來算,10個php-cgi進程就將耗掉200M內存,那系統的崩潰就應該很正常了。因此應該盡量地控制php-fpm進程的數量,大體明確其他應用占用的內存后,給它指定一個靜態的小數量,會讓系統更加平穩一些?;蛘呤褂脛討B方式,因為動態方式會結束掉多余的進程,可以回收釋放一些內存,所以推薦在內存較少的服務器或VPS上使用。具體最大數量根據 內存/20M 得到。比如說512M的VPS,建議pm.max_spare_servers設置為20。至于pm.min_spare_servers,則建議根據服務器的負載情況來設置,比較合適的值在5~10之間。
新聞熱點
疑難解答
圖片精選