php-fpm的執行方式 (進程管理模式)

php-fpm的進程數能夠根據設置分爲動態和靜態。

• 靜態：直接開啓指定數量的php-fpm進程，再也不增長或者減小；
• 動態：開始的時候開啓必定數量的php-fpm進程，當請求量變大的時候，動態的增長php-fpm進程數到上限，當空閒的時候自動釋放空閒的進程數到一個下限。

這兩種不一樣的執行方式，能夠根據服務器的實際需求來進行調整。

這裏先說一下涉及到這個的幾個參數吧，他們分別是pm、pm.max_children、pm.start_servers、pm.min_spare_servers和pm.max_spare_servers。

pm表示使用那種方式，有兩個值能夠選擇，就是static（靜態）或者dynamic（動態）。在更老一些的版本中，dynamic被稱做apache-like。這個要注意看配置文件給出的說明了。

下面4個參數的意思分別爲：

• pm.max_children：靜態方式下開啓的php-fpm進程數量。
• pm.start_servers：動態方式下的起始php-fpm進程數量。
• pm.min_spare_servers：動態方式下的最小php-fpm進程數量。
• pm.max_spare_servers：動態方式下的最大php-fpm進程數量。

 

若是dm設置爲static，那麼其實只有pm.max_children這個參數生效。系統會開啓設置的數量個php-fpm進程。

若是dm設置爲dynamic，那麼pm.max_children參數失效，後面3個參數生效。系統會在php-fpm運行開始的時候啓動 pm.start_servers個php-fpm進程，而後根據系統的需求動態在pm.min_spare_servers和 pm.max_spare_servers之間調整php-fpm進程數。

那麼，對於咱們的服務器，選擇哪一種執行方式比較好呢？事實上，跟Apache同樣，咱們運行的PHP程序在執行完成後，或多或少會有內存泄露的問題。這也是爲何開始的時候一個php-fpm進程只佔用3M左右內存，運行一段時間後就會上升到20-30M的緣由了。因此，動態方式由於會結束掉多餘 的進程，能夠回收釋放一些內存，因此推薦在內存較少的服務器或者VPS上使用。具體最大數量根據 內存/20M 獲得。好比說512M的VPS，建議pm.max_spare_servers設置爲20。至於pm.min_spare_servers，則建議根據服務器的負載狀況來設置，比較合適的值在5~10之間。

而後對於比較大內存的服務器來講，設置爲靜態的話會提升效率。由於頻繁開關php-fpm進程也會有時滯，因此內存夠大的狀況下開靜態效果會更好。數量也能夠根據 內存/30M 獲得。好比說2GB內存的服務器，能夠設置爲50；4GB內存能夠設置爲100等。

 

一種是pm = static，始終保持一個固定數量的子進程，這個數由pm.max_children定義，這種方式很不靈活，也一般不是默認的。

另外一種是pm = dynamic，他是這樣的，啓動時，會產生固定數量的子進程（由pm.start_servers控制）能夠理解成最小子進程數，而最大子進程數則由pm.max_children去控制，OK，這樣的話，子進程數會在最大和最小數範圍中變化，尚未完，閒置的子進程數還能夠由另2個配置控制，分別是pm.min_spare_servers和pm.max_spare_servers，也就是閒置的子進程也能夠有最小和最大的數目，而若是閒置的子進程超出了pm.max_spare_servers，則會被殺掉。

能夠看到，pm = dynamic模式很是靈活，也一般是默認的選項。可是，dynamic模式爲了最大化地優化服務器響應，會形成更多內存使用，由於這種模式只會殺掉超出最大閒置進程數（pm.max_spare_servers）的閒置進程，好比最大閒置進程數是30，最大進程數是50，而後網站經歷了一次訪問高峯，此時50個進程所有忙碌，0個閒置進程數，接着過了高峯期，可能沒有一個請求，因而會有50個閒置進程，可是此時php-fpm只會殺掉20個子進程，始終剩下30個進程繼續做爲閒置進程來等待請求，這可能就是爲何過了高峯期後即使請求數大量減小服務器內存使用卻也沒有大量減小，也多是爲何有些時候重啓下服務器狀況就會好不少，由於重啓後，php-fpm的子進程數會變成最小閒置進程數，而不是以前的最大閒置進程數。

第三種 pm = ondemand模式，這種模式和pm = dynamic相反，把內存放在第一位，他的工做模式很簡單，每一個閒置進程，在持續閒置了pm.process_idle_timeout秒後就會被殺掉，有了這個模式，到了服務器低峯期內存天然會降下來，若是服務器長時間沒有請求，就只會有一個php-fpm主進程，固然弊端是，遇到高峯期或者若是pm.process_idle_timeout的值過短的話，沒法避免服務器頻繁建立進程的問題，所以pm = dynamic和pm = ondemand誰更適合視實際狀況而定。

 

附各參數說明：

pm string
設置進程管理器如何管理子進程。可用值：static，ondemand，dynamic。必須設置。

static - 子進程的數量是固定的（pm.max_children）。ondemand - 進程在有需求時才產生（當請求時，與 dynamic 相反，pm.start_servers 在服務啓動時即啓動。dynamic - 子進程的數量在下面配置的基礎上動態設置：pm.max_children，pm.start_servers，pm.min_spare_servers，pm.max_spare_servers。pm.max_children intpm 設置爲 static 時表示建立的子進程的數量，pm 設置爲 dynamic 時表示最大可建立的子進程的數量。必須設置。該選項設置能夠同時提供服務的請求數限制。相似 Apache 的 mpm_prefork 中 MaxClients 的設置和 普通PHP FastCGI中的 PHP_FCGI_CHILDREN 環境變量。pm.start_serversin設置啓動時建立的子進程數目。僅在 pm 設置爲 dynamic 時使用。默認值：min_spare_servers + (max_spare_servers - min_spare_servers) / 2。pm.min_spare_servers int設置空閒服務進程的最低數目。僅在 pm 設置爲 dynamic 時使用。必須設置。pm.max_spare_servers int設置空閒服務進程的最大數目。僅在 pm 設置爲 dynamic 時使用。必須設置。pm.max_requests int設置每一個子進程重生以前服務的請求數。對於可能存在內存泄漏的第三方模塊來講是很是有用的。若是設置爲 '0' 則一直接受請求，等同於 PHP_FCGI_MAX_REQUESTS 環境變量。默認值：0。