PHP-FPM 調優：使用 ‘pm static’ 來最大化你的服務器負載能力

讓咱們來迅速瞭解一下怎樣設置 PHP-FPM，以便達到高吞吐，低延遲以及穩定的使用 CPU 和內存的完美狀態。在默認的狀況下，大多數設置都將 PHP-FPM PM（進程管理器）設置爲 dynamic ，或者當你有可用內存的問題時常建議你使用 ondemand。接下來，讓咱們根據 php.net 的官方文檔來比較一下這兩個管理選項和我最經常使用的設置 —— static 之間的區別：

• pm = dynamic：子進程的數量是根據如下指令來動態生成的：pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
• pm = ondemand：在服務啓動的時候根據 pm.start_servers 指令生成進程，而非動態生成。
• pm = static：子進程的數量是由 pm.max_children 指令來肯定的。

查看完整列表，深刻了解 php-fpm.conf 的全部指令。

PHP-FPM 進程管理器（PM）和 CPUFreq Governor 的類似之處

如今，咱們要說些偏離主題，但我以爲和 PHP-FPM 調優有關的事情。好了，咱們都有過在某些時候的 CPU 緩慢問題，不管是筆記本電腦、VM 或者是專用的服務器。還記得 CPU 頻率縮放問題嗎？（CPUFreq governor）這些設置在類 Unix 系統和 Windows 上是有效的，能夠經過修改 CPU governor，將其從 ondemand 修改成 performance 來提升性能並加快系統的響應。如今，讓咱們來比較下列 CPUFreq governor 描述和 PHP-FPM PM 有哪些類似之處：

• Governor = ondemand：根據當前負荷動態調整 CPU 頻率。先將 CPU 頻率調整至最大，而後隨着空閒時間的增長而縮小頻率。
• Governor = conservative：根據當前負荷動態調整頻率。比設置成 ondemand 更加緩慢。
• Governor = performance：始終以最大頻率運行 CPU。

查看 CPUFreq governor 選項詳細列表 ，獲取更多相關信息。

注意到類似之處了嗎？這就是我這個比較的首要目的，爲了找到一個最好的方式來寫這篇文章，推薦你將 PHP-FPM 的 pm static 看成你的第一選擇。

使用 CPU Governor 的 performance 設置是一個很是安全的性能提高方式，由於它能完美的使用你服務器 CPU 的所有性能。惟一須要考慮的因素就是一些諸如散熱、電池壽命（筆記本電腦）和一些由 CPU 始終保持 100% 所帶來的一些反作用。一旦設置爲 performance，那麼它確實是你 CPU 最快的設置。相關實例請閱讀 'force_turbo' 在 Raspberry Pi 上的設置，它教你在 RPi 板上使用 performance Governor，因爲 CPU 時鐘速度較低，性能改善將更加明顯。

使用 pm static 優化你的服務器性能

PHP-FPM 的 static 設置取決於你服務器有多少閒置內存。大多數狀況下，若是你服務器的內存不足，那麼 PM 設置成 ondemand 或 dynamic 將是更好的選擇。可是，一旦你有可用的閒置內存，那麼把 PM 設置成 static 的最大值將減小許多 PHP 進程管理器（PM）所帶來的開銷。換句話說，你應該在沒有內存不足和緩存壓力的狀況下使用 pm.static 來設置 PHP-FPM 進程的最大數量。此外，也不能影響到 CUP 的使用和其餘待處理的 PHP-FPM 操做。

在上面的截圖中，這臺服務器的設置（ pm = static，pm.max_children =100）最多使用了 10GB 的內存。請注意高亮的列。Google 分析圖中大概有 200 個活躍用戶（60秒內）。在這種用戶量下，有 70% 的 PHP-FPM 子進程被閒置。這意味着，不管當前流量如何，PHP-FPM 始終保持着足夠多的進程。閒置的進程始終保持在線，就算達到了流量的峯值也能快速響應，而不是等待 PM 生成子進程，而後在 x pm.process_idle_timeout 秒後將此進程結束。我將  pm.max_requests 設置的很是高，由於這是一個不可能發生內存泄漏的 PHP 生產服務器。若是你對你的 PHP 腳本有着 110% 的信心，那麼你可用選擇使用 pm.max_requests = 0。但建議適當的重啓服務。將請求數量設置的很高，是爲了不太高的 PM 開銷。例如，設置 pm.max_requests = 1000 ，但這須要根據 pm.max_children 的設置和實際每秒的請求數量來決定。

截圖使用  Linux top 經過 'u'（user）選項和 PHP-FPM 用戶名進行過濾。並只顯示了前 50 個左右（未統計）的進程，但基本上 top 命令也只會顯示適合你終端窗口大小的內容 —— 在本例中，使用 %CPU 排序。要查看所有的 100 條 PHP-FPM 進程的話，你須要使用如下命令：

top -bn1 | grep php-fpm

什麼時候使用 ondemand 和 dynamic

使用 pm dynamic，您可能會出現相似於下面的錯誤：

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

您可能會嘗試調整 pm 配置，但仍然會看到一樣的錯誤\
在這種狀況下，pm.min 過低，而且由於流量和峯值波動很大，使用 pm dynamic 可能難以調整

通常的建議是使用 pm ondemand。 然而，狀況會變的更糟，由於 ondemand 會在沒有流量時關閉空閒進程，而後最終會產生與流量波動很大同樣的開銷問題 (除非您設置空閒超時的時間很是很是的長）

可是，當您擁有多個 pm 進程池時，pm dynamic， 特別是 ondemand 是能夠爲您節省時間的。例如在共享的 VPS 上，有 100+ 的 cPanel 帳號和 200+ 的域名，使用 pm.static 或者是 pm.dynamic 都是不可能的，即便在沒有任何流量的狀況下，內存會被瞬間用完，而 pm.ondemand 意味着全部空閒的子進程都會被徹底關閉，節省了大量內存。cPanel 的開發者已經意識到了這個問題，如今的 cPanel 默認就是設置爲 pm.ondemand。

結論

當流量波動比較大的時候，，PHP-FPM 的 ondemand 和 dynamic 會由於固有開銷而限制吞吐量。 您須要瞭解您的系統並設置 PHP-FPM 進程數，以匹配服務器的最大容量。\
從 pm.max_children 開始，根據 pm dynamic 或 ondemand 的最大使用狀況去設置

您會注意到，在 pm static 模式下，由於您將全部內容都保存在內存中，因此隨着時間的推移，流量峯值會對 CPU 形成比較小的峯值，而且您的服務器負載和 CPU 平均值將變得更加平滑。 每一個須要手動調整的 PHP-FPM 進程數的平均大小會有所不一樣

更新：附上一張 A/B 測試圖。

轉自 PHP / Laravel 開發者社區 https://laravel-china.org/top...