php-fpm調整：使用＆＃x27; pm static＆＃x27;用於最大性能

關鍵要點

• 對於內存充足的服務器，PHP-FPM 的 pm static 設置可提供高吞吐量和低延遲。此設置使 PHP-FPM 進程始終保持最大容量，能夠快速響應流量峰值，無需生成新的進程。
• 使用 pm static 需要仔細調整，以避免內存不足或緩存壓力問題。 pm.max_children 應根據服務器在不影響 CPU 性能的情況下能夠處理的 PHP-FPM 進程最大數量來設置。
• 對於具有多個 PHP-FPM 池或內存較低的服務器，pm dynamic 或 pm ondemand 可能更合適。這些設置根據當前負載調整子進程的數量，可以節省內存，但也可能導致流量波動時的開銷問題。
• 無論選擇哪種設置，定期監控和調整 PHP-FPM 配置對於獲得最佳性能至關重要。 PHP-FPM 進程的平均大小因服務器而異，需要手動調整併清楚地了解服務器的資源和流量模式。

文章原稿未經編輯，最初發表於 HaydenJames.io，經作者許可在此轉載。

讓我們快速了解如何最佳設置 PHP-FPM 以實現高吞吐量、低延遲以及更穩定的 CPU 和內存使用。默認情況下，大多數設置將 PHP-FPM 的 PM（進程管理器）字符串設置為 dynamic，如果遇到可用內存問題，通常建議使用 ondemand。但是，讓我們根據 php.net 的文檔比較這兩個管理選項，並比較我最喜歡的用於高流量設置的選項——static pm：

• pm = dynamic：子進程的數量根據以下指令動態設置：pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers。
• pm = ondemand：進程按需在請求時生成，這與 dynamic 不同，dynamic 在服務啟動時啟動 pm.start_servers。
• pm = static：子進程的數量由 pm.max_children 固定。

請參閱完整的全局 php-fpm.conf 指令列表以了解更多詳細信息。

PHP-FPM 進程管理器 (PM) 與 CPUFreq 調節器的相似之處

這看起來可能有點離題，但我希望將其與我們的 PHP-FPM 調整主題聯繫起來。好的，我們都在某些時候遇到過 CPU 速度慢的問題，無論是筆記本電腦、虛擬機還是專用服務器。還記得 CPU 頻率縮放嗎？ （CPUFreq 調節器。）這些設置在 nix 和 Windows 系統上都可用，可以通過將 CPU 調節器設置從 ondemand 更改為 performance* 來提高性能和系統響應能力。這次，讓我們比較一下描述並尋找相似之處：

• Governor = ondemand：根據當前負載動態縮放 CPU 頻率。跳到最高頻率，然後隨著空閒時間的增加而降低頻率。
• Governor = conservative：根據當前負載動態縮放頻率。比 ondemand 更平緩地縮放頻率。
• Governor = performance：始終以最大頻率運行 CPU。

請參閱完整的 CPUFreq 調節器選項列表以了解更多詳細信息。

注意到相似之處了嗎？我想先使用這個比較，目的是找到最佳方法來撰寫一篇文章，推薦將 PHP-FPM 的 pm static 作為您的首選。

對於 CPU 調節器，performance 設置是一個相當安全的性能提升，因為它幾乎完全取決於您服務器 CPU 的限制。其他因素只有諸如熱量、電池壽命（筆記本電腦）以及將 CPU 頻率永久設置為 100% 的其他副作用。一旦設置為 performance，它確實是 CPU 最快的設置。例如，閱讀關於 Raspberry Pi 上的 force_turbo 設置的信息，該設置強制您的 RPi 板使用 performance 調節器，由於 CPU 時鐘速度低，性能改進更為明顯。

使用 pm static 實現服務器的最大性能

PHP-FPM pm static 設置在很大程度上取決於服務器有多少可用內存。基本上，如果您遇到服務器內存不足的問題，那麼 pm ondemand 或 dynamic 可能是更好的選擇。另一方面，如果您有足夠的可用內存，則可以通過將 pm static 設置為服務器的最大容量來避免大部分 PHP 進程管理器 (PM) 開銷。換句話說，當您進行計算時，pm.static 應設置為在不創建內存可用性或緩存壓力問題的情況下可以運行的 PHP-FPM 進程的最大數量。此外，不要設置得太高以至於壓垮 CPU(s) 並導致大量未處理的 PHP-FPM 操作。

在上圖中，此服務器的 pm = static 和 pm.max_children = 100，最多使用約 10GB 的 32GB 已安裝內存。請注意自解釋的高亮列。在該屏幕截圖期間，Google Analytics 中大約有 200 個“活躍用戶”（過去 60 秒）。在這個級別，大約 70% 的 PHP-FPM 子進程仍然處於空閒狀態。這意味著 PHP-FPM 始終設置為服務器資源的最大容量，而不管當前流量如何。空閒進程保持在線，等待流量峰值並立即響應，而不是必須等待 pm 生成子進程，然後在 pm.process_idle_timeout 到期後將其關閉。我已經將 pm.max_requests 設置得非常高，因為這是一個沒有 PHP 內存洩漏的生產服務器。如果您對當前和未來的 PHP 腳本有 110% 的信心，則可以在 static 中使用 pm.max_requests = 0。但是，建議定期重新啟動腳本。將請求數設置為一個較高的數字，因為重點是避免 pm 開銷。例如，至少 pm.max_requests = 1000，具體取決於您的 pm.max_children 數量和每秒請求數。

該屏幕截圖使用 Linux top，按“u”（用戶）選項和 PHP-FPM 用戶的名稱進行過濾。顯示的進程數量只有大約 50 個（沒有計算），但基本上 top 顯示適合您終端窗口的頂級統計信息——在本例中，按 %CPU 排序。要查看所有 100 個 PHP-FPM 進程，您可以使用以下命令：

<code>top -bn1 | grep php-fpm</code>

何時使用 pm ondemand 和 dynamic

使用 pm dynamic，您可能已經註意到類似以下的錯誤：

<code>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</code>

您可能會嘗試增加/調整設置，但仍然會看到與 Serverfault 帖子中某人描述的相同的錯誤。在這種情況下，pm.min 太低，並且由於網絡流量隨著低谷和峰值的波動而波動很大，因此很難正確調整 pm dynamic。通常的建議是使用 pm ondemand。但是，這更糟糕，因為當流量很少或沒有流量時，ondemand 會將空閒進程關閉到0，然後您最終會遇到與流量波動一樣多的開銷問題——除非，當然，您將空閒超時設置為極高……在這種情況下，您應該只使用pm.static 高pm.max_requests。

但是，當您有多個 PHP-FPM 池時，PM dynamic，尤其是 ondemand 可以為您節省資源。例如，託管多個 cPanel 帳戶或不同池下的多個網站。例如，我有一台服務器，擁有 100 多個 cPanel 帳戶和大約 200 多個域名，pm.static 甚至 dynamic 都無法很好地執行。只有 ondemand 才能很好地執行，因為超過三分之二的網站幾乎沒有流量。使用 ondemand，這意味著所有子進程都將關閉，從而節省大量服務器內存！值得慶幸的是，cPanel 開發人員已經解決了這個問題，現在它默認為 ondemand。以前，由於默認情況下使用 dynamic，即使在空閒的 cPanel PHP-FPM 池/帳戶上，它也使 PHP-FPM 成為共享服務器上的一個選項。如果您收到良好的流量，您不太可能託管在具有大量 PHP-FPM 池（共享主機）的服務器上。

結論

在 PHP-FPM 中，一旦您開始提供大量的流量，PHP-FPM 的 ondemand 和 dynamic 進程管理器可能會由於固有的開銷而限制吞吐量。了解您的系統，並將您的 PHP-FPM 進程設置為匹配服務器的最大容量。從基於 pm dynamic 或 ondemand 的最大使用量設置 pm.max_children 開始，然後增加到內存和 CPU 能夠處理而不會不堪重負的程度。您會注意到，使用 pm static，因為您讓所有內容都駐留在內存中，因此隨著時間的推移，流量峰值會導致 CPU 的峰值減少，並且服務器的負載和 CPU 平均值將更加平滑。您的 PHP-FPM 進程的平均大小因 Web 服務器而異，需要手動調整，因此為什麼更自動化的開銷進程管理器——dynamic 和 ondemand——更受歡迎的建議。希望這篇文章對您有所幫助。

更新：添加了 A/B 基準比較圖表。讓 PHP-FPM 進程駐留在內存中有助於提高性能，但代價是增加內存使用量以使其處於等待狀態。找到您的設置最佳點。

關於 PHP-FPM 調整的常見問題解答 (FAQ)

什麼是 PHP-FPM，為什麼它對我的服務器性能很重要？

PHP-FPM 或 FastCGI 進程管理器是另一種 PHP FastCGI 實現，它具有一些對任何規模的站點（尤其是一些繁忙的站點）有用的附加功能。它對服務器性能很重要，因為它允許服務器通過利用工作進程池來處理更多同時訪問者的請求。這些進程負責解析 PHP 文件、生成動態內容並將其提供給客戶端。通過有效地管理這些進程，PHP-FPM 可以顯著提高服務器的性能和可擴展性。

PHP-FPM 如何提高我的網站性能？

PHP-FPM 通過有效管理 PHP 進程來提高網站性能。它使用主進程來控制多個子進程，這些子進程處理 PHP 腳本。這允許有效地使用服務器資源，因為可以終止空閒進程，並且可以根據需要生成新進程。此外，PHP-FPM 支持操作碼緩存，這可以通過將預編譯的腳本字節碼存儲在共享內存中來顯著加快 PHP 執行速度，從而無需 PHP 在每次請求時加載和解析腳本。

PHP-FPM 中的 pm static 配置是什麼，它如何影響性能？

PHP-FPM 中的 pm static 配置將子進程的數量設置為固定數量。這意味著始終會有特定數量的進程準備好為傳入請求提供服務，而不管當前服務器負載如何。這可以在高負載下帶來更好的性能，因為不需要生成新進程。但是，它也可能導致更高的內存使用率，因為即使不需要這些進程，它們也始終在運行。

如何調整 PHP-FPM 以獲得最大性能？

調整 PHP-FPM 以獲得最大性能涉及調整多個配置設置。這些設置包括確定要使用的進程管理器的 pm 設置，以及設置子進程最大數量的 pm.max_children 設置。其他重要設置包括 pm.start_servers、pm.min_spare_servers 和 pm.max_spare_servers，它們分別控制啟動的服務器數量、空閒服務器的最小數量和最大數量。將這些設置調整為匹配服務器的資源和流量模式可以顯著提高性能。

PHP-FPM 的一些常見問題是什麼，我該如何對其進行故障排除？

PHP-FPM 的一些常見問題包括高 CPU 使用率、響應時間慢以及與達到子進程最大數量相關的錯誤。這些問題通常可以通過調整 PHP-FPM 配置設置來解決，例如增加 pm.max_children 設置或切換到不同的進程管理器。此外，監控工具可用於識別瓶頸和性能問題。

PHP-FPM 與其他 PHP 處理程序相比如何？

PHP-FPM 通常被認為比其他 PHP 處理程序更高效、更靈活。它支持各種進程管理器，可以根據服務器的資源和流量模式進行調整。此外，PHP-FPM 支持操作碼緩存，並且可以處理大量同時請求，這使其成為繁忙站點的理想選擇。

我可以將 PHP-FPM 與任何 Web 服務器一起使用嗎？

是的，PHP-FPM 可以與任何支持 FastCGI 協議的 Web 服務器一起使用。這包括流行的 Web 服務器，如 Apache、Nginx 和 Lighttpd。

什麼是操作碼緩存，它如何提高 PHP 性能？

操作碼緩存是一種通過將預編譯的腳本字節碼存儲在共享內存中來提高 PHP 性能的技術。這無需 PHP 在每次請求時加載和解析腳本，從而縮短了執行時間。

如何監控 PHP-FPM 的性能？

有幾種工具可用於監控 PHP-FPM 的性能。這些工具包括 PHP-FPM 狀態頁面（提供有關工作進程當前狀態的信息）以及各種命令行工具，如 top 和 ps。此外，還有一些第三方監控解決方案提供更詳細的指標和警報。

使用 PHP-FPM 的一些最佳實踐是什麼？

使用 PHP-FPM 的一些最佳實踐包括：將進程管理器設置調整為匹配服務器的資源和流量模式；啟用操作碼緩存；定期監控性能以識別和解決問題。此外，務必使 PHP-FPM 和 Web 服務器軟件保持最新狀態，以利用最新的性能改進和安全修復。

以上是php-fpm調整：使用＆＃x27; pm static＆＃x27;用於最大性能的詳細內容。更多資訊請關注PHP中文網其他相關文章！