導言：Web伺服器的CPU指標和MEM指標異常，不穩定？可能是PHP-FPM程序重啟機制的問題導致的，一同和百度外賣探索下如何優化吧。

作者簡介：

猛哥
百度外賣基礎架構部線上開發方向負責人
負責線上開發框架的持續優化和長期演進，主導研發的WFE/WODP/WOSP組成一套完整高效的WEB架構，支撐百度外賣所有線上服務高速高質量地發展。

百度外賣基礎架構部線上開發團隊
擅長自底向上地創造和優化基礎框架、基礎庫和基礎服務，對NGINX和PHP有深層次的理解和創新性的改造。天下大事必作於細，百度外賣基礎架構部線上開發團隊，將持續精耕細作，適時釋出成熟有效的線上服務優化方案，期待與同行保持交流，共同進步。

摘要

通過優化PHP-FPM程序重啟機制，改善線上伺服器CPU_IDLE和MEM_USED波動的問題，使伺服器資源利用率更加平滑可靠。

背景

外賣交易服務叢集報出在監控圖上CPU_IDLE波動劇烈，如圖所示。

事實上一直以來，不僅PU_IDLE存在一定的波動，MEM_USED的週期性斷崖式下降再回升也早已司空見慣。那麼CPU_IDLE與MEM_UESD的波動是否存在關聯，追溯這種現象產生的原因，我們就必須理解PHP-FPM程序管理器的機制。

原理

在PHP5.3.3版本中，PHP-FPM正式被官方收編，作為FastCGI管理器，支援平滑停止啟動程序、slow-log、動態程序、執行狀態等特性。

PHP-FPM程序管理支援三種方式：static、dynamic、ondemand。我們選用的是static方式，即PHP-FPM生成固定數量的FastCGI程序，這種方式比較簡單，避免了頻繁開啟關閉程序的開銷。（線上下虛擬機器環境中，程序管理可以配置成ondemand，既降低了記憶體需求又避免了程序數量不夠用）

回到面臨的問題上，CPU_IDLE和MEM_USED的週期性波動是如何產生的。首先這是一種所有的叢集都存在的現象，然後交易服務叢集表現尤為突出。在排查了應用程式（比如日誌採集程式、定時指令碼）的影響後，思路落在了PHP-FPM的一個關鍵引數上：max_requests。

max_requests

但是經過觀察發現，CPU_IDLE和MEM_USED週期性波動的問題並沒有根除，效果如圖。

這很好理解，我們調大max_requests引數，但是FastCGI重啟機制依然生效，每個請求都會計數，當計數到達max_request之後，cgi程序會執行 fcgi_finish_request退出程序，子程序退出，fpm-master程序會收到SIGCHLD訊號，執行fpm_children_bury重啟程序，重啟的方式是fork一個子程序。

FastCGI程序通過unix socket承接Nginx請求，負載較為均衡，生產環境流量大，PHP程序數配置較大，數以百計的FastCGI會在同一時間到達 max_requests上限而進行重啟，這便造成了CPU_IDLE和MEM_USED週期性波動。

優化

max_requests的初衷是為了避免第三方擴充套件引起的記憶體洩漏問題，雖然線上環境使用的擴充套件經過分析和測試，並沒有嚴重的記憶體洩漏問題，但是由於擴充套件內部使用的第三方庫太多，並無法完全避免記憶體洩漏問題，同時max_requests機制很適合FastCGI多程序環境，以較小的代價，換取記憶體洩漏的長治久安。

為了避免CPU_IDLE和MEM_USED週期波動，同時保持max_requests機制，需要在PHP-FPM原始碼上稍作修改。FastCGI程序在啟動時，設定max_requests，此時只要將max_requests配置引數雜湊開，使FastCGI程序分別配置不同的值，即可達到效果。

具體程式碼在sapi/fpm/fpm/fpm.c，修改如下：

php_mt_srand(GENERATE_SEED()); *max_requests=fpm_globals.max_requests+php_mt_rand()&8191;

總結

經過修改上線，對比效果見下圖

至此CPU_IDLE和MEM_USED已經告別了週期性波動，避免了CPU計算資源產生浪湧效果，記憶體佔用資料也更加真實可靠。

以此文拋磚引玉，PHP-FPM在生產環境的精細優化，任重而道遠。

文章來自微信公眾號：高效運維