php-fpm 配置中pm的選擇

另附豆瓣技術貼:https://www.douban.com/note/315222037/

 

一、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的緣由了。
對於內存大的服務器（好比8G以上）來講，指定靜態的max_children實際上更爲穩當，由於這樣不須要進行額外的進程數目控制，會提升效率。
由於頻繁開關php-fpm進程也會有時滯，因此內存夠大的狀況下開靜態效果會更好。數量也能夠根據 內存/30M 獲得，好比8GB內存能夠設置爲100，
那麼php-fpm耗費的內存就能控制在 2G-3G的樣子。若是內存稍微小點，好比1G，那麼指定靜態的進程數量更加有利於服務器的穩定。
這樣能夠保證php-fpm只獲取夠用的內存，將很少的內存分配給其餘應用去使用，會使系統的運行更加暢通。
對於小內存的服務器來講，好比256M內存的VPS，即便按照一個20M的內存量來算，10個php-cgi進程就將耗掉200M內存，那系統的崩潰就應該很正常了。
所以應該儘可能地控制php-fpm進程的數量，大致明確其餘應用佔用的內存後，給它指定一個靜態的小數量，會讓系統更加平穩一些。或者使用動態方式，
由於動態方式會結束掉多餘的進程，能夠回收釋放一些內存，因此推薦在內存較少的服務器或VPS上使用。具體最大數量根據 內存/20M 獲得。
好比說512M的VPS，建議pm.max_spare_servers設置爲20。至於pm.min_spare_servers，則建議根據服務器的負載狀況來設置，好比服務器上只是部署php環境的話，比較合適的值在5~10之間。

 

可是爲何要重啓進程呢？

通常在項目中，咱們多多少少都會用到一些 PHP 的第三方庫，這些第三方庫常常存在內存泄漏問題，若是不按期重啓 PHP-CGI 進程，勢必形成內存使用量不斷增加。所以 PHP-FPM 做爲 PHP-CGI 的管理器，提供了這麼一項監控功能，對請求達到指定次數的 PHP-CGI 進程進行重啓，保證內存使用量不增加。

正是由於這個機制，在高併發的站點中，常常致使 502 錯誤，我猜想緣由是 PHP-FPM 對從 NGINX 過來的請求隊列沒處理好。不過我目前用的仍是 PHP 5.3.2，不知道在 PHP 5.3.3 中是否還存在這個問題。

目前咱們的解決方法是，把這個值儘可能設置大些，儘量減小 PHP-CGI 從新 SPAWN 的次數，同時也能提升整體性能。在咱們本身實際的生產環境中發現，內存泄漏並不明顯，所以咱們將這個值設置得很是大（204800）。你們要根據本身的實際狀況設置這個值，不能盲目地加大。