PHP-FPM 設定：使用 pm static 以獲得最大效能

本文的未經編輯版本最初發表於 海登詹姆斯.io 並經她許可在此發布 阿夫托拉.

我將簡要告訴您如何最好地配置 PHP-FPM 以提高吞吐量、減少延遲並更一致地使用 CPU 和記憶體。預設情況下，PHP-FPM 中的 PM（進程管理器）行是 動態，如果你沒有足夠的內存，那麼最好安裝 按需。讓我們根據 php.net 文件比較 2 個控制選項，看看我最喜歡的與它們有何不同 靜止 高峰流量請pm：

pm = 動態 — 子程序的數量是根據以下指令動態配置的： pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers.
pm = 點播 - 進程是按需建立的（與動態建立相反，當服務啟動時啟動 pm.start_servers 時）。
pm = 靜態 — 子程序的數量是固定的，由參數指示 pm.max_children.

詳細資訊請參見 全域指令 php-fpm.conf 的完整列表.

PHP-FPM進程管理器與CPU頻率控制器之間的相似之處

這可能看起來偏離主題，但我將把它連結到 PHP-FPM 配置主題。誰沒有經歷過至少一次處理器速度下降的情況——在筆記型電腦、虛擬機器或專用伺服器上。還記得 CPU 頻率縮放嗎？這些選項可用於 nix 和 Windows 可以透過更改處理器節流設定來提高系統效能和回應能力 按需 上 表現*。這次，我們來比較一下描述，看看有什麼相似之處：

調速器=點播 — 根據目前負載動態調整處理器頻率。快速跳至最大頻率，然後隨著不活動時間的增加而降低頻率。
州長=保守= 根據目前負載進行動態頻率縮放。比按需更平滑地增加和減少頻率。
調速器=性能 — 頻率始終是最大的。

詳細資訊請參見 處理器頻率調節器參數的完整列表.

看到相似之處了嗎？我想透過這個比較來說服您最好使用 下午靜態 對於 PHP-FPM。

對於處理器調節器參數 性能 有助於安全地提高效能，因為它幾乎完全取決於伺服器的 CPU 限制。當然，除此之外，還有溫度、電池電量（在筆記型電腦中）以及處理器持續以 100% 運行的其他副作用等因素。效能設定可確保最快的處理器效能。例如，閱讀有關 樹莓派中的force_turbo參數，RPi 面板將使用調節器 性能，由於 CPU 時脈速度較低，效能提升會更加明顯。

使用 pm static 實現最大伺服器效能

PHP-FPM 選項 下午靜態 很大程度上取決於伺服器上的可用記憶體。如果記憶體較低，最好選擇 按需 或 動態。另一方面，如果你有內存，你可以透過設定 pm 來避免 PHP 進程管理器的開銷 靜止 到最大伺服器容量。換句話說，如果一切都計算得很好，你需要建立 靜態 可以執行的 PHP-FPM 進程的最大數量， 不會產生記憶體或快取不足的問題。但不要太高，以免壓垮處理器並累積一堆等待執行的 PHP-FPM 操作.

在上面的螢幕截圖中，伺服器有 pm = 靜態且 pm.max_children = 100，這佔用了可用 10 GB 中的大約 32 GB。請注意突出顯示的列，這裡的一切都很清楚。在此螢幕截圖中，Google Analytics 中有大約 200 個活躍用戶（超過 60 秒）。在此級別，大約 70% 的 PHP-FPM 子進程仍然處於空閒狀態。這意味著無論當前流量如何，PHP-FPM 始終設定為最大伺服器資源量。空閒進程等待流量高峰並立即回應。你不必等到 pm 將建立子進程，然後在期限到期時終止它們 pm.process_idle_timeout。我將值設為非常高 pm.最大請求數因為這是一個 PHP 中沒有記憶體洩漏的工作伺服器。您可以安裝 pm.max_requests = 0 如果您對現有和未來的 PHP 腳本完全有信心，請使用 static。但最好隨著時間的推移重新運行腳本。設定大量的請求，因為我們想避免不必要的pm成本。例如，至少 pm.max_requests = 1000 - 取決於數量 pm.max_children 以及每秒的請求數。

螢幕截圖顯示了該命令 Linux 頂層，按 u（使用者）和 PHP-FPM 使用者名稱過濾。僅顯示前 50 個左右的進程（我沒有準確統計），但本質上 top 顯示了適合終端視窗的頂部統計資料。在本例中按 CPU 百分比 (%CPU) 排序。若要查看所有 100 個 PHP-FPM 進程，請執行下列命令：

top -bn1 | grep php-fpm

何時使用pm ondemand 和dynamic

如果你用pm 動態，會出現這樣的錯誤：

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

嘗試更改參數，錯誤不會消失，例如 這篇關於 Serverfault 的文章中描述了。本例中pm.min值太小，且網路流量波動較大，峰值高谷深，難以充分調整pm 動態。通常使用 pm 按需, 正如同一篇文章中所建議的。但這更糟，因為 按需 當流量很少或沒有流量時，將空閒進程終止為零，並且您仍然會因更改流量而產生開銷。當然，除非您設定了很長的等待時間。然後使用比較好 靜態 + 高數 pm.最大請求數.

PM 動態 特別是 按需 如果您有多個 PHP-FPM 池，可能會派上用場。例如，您在不同的池中託管多個 cPanel 帳戶或多個網站。我的伺服器有 100 多個 cpanel 帳戶和大約 200 個網域，pm.static 甚至動態都無法拯救我。你需要的只是這裡 按需，畢竟，超過三分之二的網站收到的流量很少或沒有，而且 按需 所有子進程都會脫落，這將為我們節省大量記憶體！幸運的是，cPanel 開發人員注意到了這一點並將該值設為預設值 按需。以前，當預設值是 動態，PHP-FPM 根本不適合繁忙的共享伺服器。很多人都用過 超PHP, 因為下午 動態 即使池和 cPanel PHP-FPM 帳戶處於空閒狀態，也會消耗記憶體。最有可能的是，如果流量良好，您將不會託管在具有大量 PHP-FPM 池（共享託管）的伺服器上。

結論

如果您使用 PHP-FPM 並且流量很大，流程管理器 按需 и 動態 PHP-FPM 由於其固有的開銷，吞吐量將受到限制。了解您的系統並根據最大伺服器容量配置PHP-FPM進程。第一組 pm.max_children 取決於 pm 的最大使用量 動態 或 按需，然後將該值增加到記憶體和處理器能夠正常工作而不會過載的水平。你會注意到 下午靜態，由於所有內容都在記憶體中，隨著時間的推移，流量峰值將導致 CPU 峰值減少，伺服器和 CPU 負載平均值將趨於平穩。平均 PHP-FPM 進程大小取決於 Web 伺服器，並且需要手動配置，因此更自動化的進程管理器 動態 и 按需 - 更流行。我希望這篇文章有用。

UPD 新增了基準圖表 ab。如果 PHP-FPM 進程位於記憶體中，則效能的提高是以它們等待的記憶體消耗為代價的。找到最適合自己的選擇。

來源： www.habr.com