php-fpm 啟動參數及重要配置詳解
約定幾個目錄
二,php-fpm.conf重要參數詳解
三,常見錯誤及解決方法整理
1,request_terminate_timeout所造成的資源問題
request_terminate_timeout的值如果設定為0或過長的時間,可能會造成file_get_contents的資源問題。
如果file_get_contents請求的遠端資源如果反應過慢,file_get_contents就會一直卡在那裡不會逾時。我們知道php.ini 裡面max_execution_time 可以設定 PHP 腳本的最大執行時間,但是,在 php-cgi(php-fpm) 中,這個參數不會起效。真正能夠控制 PHP 腳本最大執行時間的是 php-fpm.conf 設定檔中的request_terminate_timeout參數。
request_terminate_timeout預設值為 0 秒,也就是說,PHP 腳本會一直執行下去。這樣,當所有的 php-cgi 進程都卡在 file_get_contents() 函數時,這台 Nginx+PHP 的 WebServer 已經無法再處理新的 PHP 請求了,Nginx 就會給使用者回傳「502 Bad Gateway」。修改此參數,設定一個 PHP 腳本最大執行時間是必要的,但是,治標不治本。例如改成 30s,如果發生 file_get_contents() 取得網頁內容較慢的情況,這意味著 150 個 php-cgi 進程,每秒鐘只能處理 5 個請求,WebServer 同樣很難避免」502 Bad Gateway」。解決辦法是request_terminate_timeout設定為10s或一個合理的值,或是為file_get_contents加上一個逾時參數。
2,max_requests參數配置不當,可能會造成間歇性505050%
目前我們的解決方法是,把這個值盡量設定大些,盡可能減少 PHP-CGI 重新 SPAWN 的次數,同時也能提升整體效能。在我們自己實際的生產環境中發現,記憶體洩漏並不明顯,因此我們將這個值設定得非常大(204800)。大家要依照自己的實際狀況設定這個數值,不能盲目地加大。
3,php-fpm的慢日誌,debug及異常排查神器:
request_slowlog_timeout設定一個超時的參數,slowlog設定慢日誌的存放位置
-f /var/log/www
.slow.log