約定幾個目錄
一,php-fpm的啟動參數(shù)
二,php-fpm.conf重要參數(shù)詳解
三,常見錯誤及解決辦法整理1,request_terminate_timeout引起的資源問題
如果file_get_contents請求的遠(yuǎn)程資源如果反應(yīng)過慢,file_get_contents就會一直卡在那里不會超時(shí)。我們知道php.ini 里面max_execution_time 可以設(shè)置 PHP 腳本的最大執(zhí)行時(shí)間,但是,在 php-cgi(php-fpm) 中,該參數(shù)不會起效。真正能夠控制 PHP 腳本最大執(zhí)行時(shí)間的是 php-fpm.conf 配置文件中的request_terminate_timeout參數(shù)。 request_terminate_timeout默認(rèn)值為 0 秒,也就是說,PHP 腳本會一直執(zhí)行下去。這樣,當(dāng)所有的 php-cgi 進(jìn)程都卡在 file_get_contents() 函數(shù)時(shí),這臺 Nginx+PHP 的 WebServer 已經(jīng)無法再處理新的 PHP 請求了,Nginx 將給用戶返回“502 Bad Gateway”。修改該參數(shù),設(shè)置一個 PHP 腳本最大執(zhí)行時(shí)間是必要的,但是,治標(biāo)不治本。例如改成 30s,如果發(fā)生 file_get_contents() 獲取網(wǎng)頁內(nèi)容較慢的情況,這就意味著 150 個 php-cgi 進(jìn)程,每秒鐘只能處理 5 個請求,WebServer 同樣很難避免”502 Bad Gateway”。解決辦法是request_terminate_timeout設(shè)置為10s或者一個合理的值,或者給file_get_contents加一個超時(shí)參數(shù)。
2,max_requests參數(shù)配置不當(dāng),可能會引起間歇性502錯誤:
設(shè)置每個子進(jìn)程重生之前服務(wù)的請求數(shù). 對于可能存在內(nèi)存泄漏的第三方模塊來說是非常有用的. 如果設(shè)置為 ’0′ 則一直接受請求. 等同于 PHP_FCGI_MAX_REQUESTS 環(huán)境變量. 默認(rèn)值: 0. 但是為什么要重啟進(jìn)程呢? 一般在項(xiàng)目中,我們多多少少都會用到一些 PHP 的第三方庫,這些第三方庫經(jīng)常存在內(nèi)存泄漏問題,如果不定期重啟 PHP-CGI 進(jìn)程,勢必造成內(nèi)存使用量不斷增長。因此 PHP-FPM 作為 PHP-CGI 的管理器,提供了這么一項(xiàng)監(jiān)控功能,對請求達(dá)到指定次數(shù)的 PHP-CGI 進(jìn)程進(jìn)行重啟,保證內(nèi)存使用量不增長。 正是因?yàn)檫@個機(jī)制,在高并發(fā)的站點(diǎn)中,經(jīng)常導(dǎo)致 502 錯誤,我猜測原因是 PHP-FPM 對從 NGINX 過來的請求隊(duì)列沒處理好。不過我目前用的還是 PHP 5.3.2,不知道在 PHP 5.3.3 中是否還存在這個問題。 目前我們的解決方法是,把這個值盡量設(shè)置大些,盡可能減少 PHP-CGI 重新 SPAWN 的次數(shù),同時(shí)也能提高總體性能。在我們自己實(shí)際的生產(chǎn)環(huán)境中發(fā)現(xiàn),內(nèi)存泄漏并不明顯,因此我們將這個值設(shè)置得非常大(204800)。大家要根據(jù)自己的實(shí)際情況設(shè)置這個值,不能盲目地加大。
3,php-fpm的慢日志,debug及異常排查神器:request_slowlog_timeout設(shè)置一個超時(shí)的參數(shù),slowlog設(shè)置慢日志的存放位置
上面的命令即可看到執(zhí)行過慢的php過程。 |
|
|