|
max_requests = N 是指當(dāng)每個(gè)children接受了N次請(qǐng)求以后,就會(huì)把自己殺死,然后重新建立一個(gè)children。
PV / max_children = 每一個(gè)children接受的request次數(shù)[ 默認(rèn)預(yù)設(shè)瀏覽一個(gè)只調(diào)用一次php程序,或許異步調(diào)用呢?接口呢?]
比如上面的值是1000,而你定義的是10240,那么fpm要超過(guò)10天才能殺死children并重建,這樣如果存在內(nèi)存泄露的話,就會(huì)導(dǎo)致進(jìn)程占用過(guò)多的內(nèi)存而無(wú)法釋放,從而使fpm的處理能力降低,還會(huì)產(chǎn)生一些莫名其妙的錯(cuò)誤。
但是如果你把這個(gè)值設(shè)置的過(guò)小,fpm頻繁的殺死children并重建,也會(huì)導(dǎo)致額外的開(kāi)銷。
最好的優(yōu)化當(dāng)然是根據(jù)你網(wǎng)站的運(yùn)行情況,去不斷的調(diào)試,找到一個(gè)平衡點(diǎn)。
針對(duì)max_children還有一個(gè)偷懶的做法,如果你的php是5.3,那么你可以把fpm的style設(shè)置為apache-like,這個(gè)時(shí)候children的數(shù)量就由fpm自動(dòng)控制。相應(yīng)的配置參數(shù)是
start_servers:起始進(jìn)程數(shù)量
min_spare_servers:最小進(jìn)程數(shù)量
max_spare_servers:最大進(jìn)程數(shù)量
當(dāng)服務(wù)器比較空閑的時(shí)候,fpm會(huì)主動(dòng)殺死一些多余的children,用來(lái)節(jié)約資源,當(dāng)服務(wù)器繁忙的時(shí)候,服務(wù)器會(huì)自動(dòng)建立更多的children。
#########################
Nginx 502 Bad Gateway的含義是請(qǐng)求的php-CGI已經(jīng)執(zhí)行,但是由于某種原因(一般是讀取資源的問(wèn)題)沒(méi)有執(zhí)行完畢而導(dǎo)致php-CGI進(jìn)程終止,
一般來(lái)說(shuō)Nginx 502 Bad Gateway和php-fpm.conf的設(shè)置有關(guān)。
php-fpm.conf有兩個(gè)至關(guān)重要的參數(shù),一個(gè)是max_children,
另一個(gè)是request_terminate_timeout,但是這個(gè)值不是通用的,而是需要自己計(jì)算的。
在安裝好使用過(guò)程中出現(xiàn)502問(wèn)題,一般是因?yàn)槟J(rèn)php-cgi進(jìn)程是5個(gè),可能因?yàn)?a href=/itjie/phpjishu/ target=_blank class=infotextkey>phpcgi進(jìn)程不夠用而造成502,需要修改/usr/local/php/etc/php-fpm.conf 將其中的max_children值適當(dāng)增加。
計(jì)算的方式如下:
如果你的服務(wù)器性能足夠好,且寬帶資源足夠充足,php腳本沒(méi)有死循環(huán)或BUG的話你可以直接將 request_terminate_timeout設(shè)置成0s。0s的含義是讓php-CGI一直執(zhí)行下去而沒(méi)有時(shí)間限制。而如果你做不到這一點(diǎn),也就 是說(shuō)你的php-CGI可能出現(xiàn)某個(gè)BUG,或者你的寬帶不夠充足或者其他的原因?qū)е履愕?a href=/itjie/phpjishu/ target=_blank class=infotextkey>php-CGI假死那么就建議你給request_terminate_timeout賦一個(gè)值,這個(gè)值可以根據(jù)服務(wù)器的性能進(jìn)行設(shè)定。一般來(lái)說(shuō)性能越好你可以設(shè)置越高,20分鐘-30分 鐘都可以。
而max_children這個(gè)值又是怎么計(jì)算出來(lái)的呢?這個(gè)值原則上是越大越好,php-cgi的進(jìn)程多了就會(huì)處理的很快,排隊(duì)的請(qǐng)求就會(huì)很少。 設(shè)置max_children也需要根據(jù)服務(wù)器的性能進(jìn)行設(shè)定,
一般來(lái)說(shuō)一臺(tái)服務(wù)器正常情況下每一個(gè)php-cgi所耗費(fèi)的內(nèi)存在20M左右。
按照官方的答案,排查了相關(guān)的可能,并結(jié)合了網(wǎng)友的答案,得出了下面的解決辦法。
1、查看php fastcgi的進(jìn)程數(shù)(max_children值)
代碼:NETstat -anpo | grep “php-cgi” | wc -l
5(假如顯示5)
2、查看當(dāng)前進(jìn)程
代碼:top
觀察fastcgi進(jìn)程數(shù),假如使用的進(jìn)程數(shù)等于或高于5個(gè),說(shuō)明需要增加(根據(jù)你機(jī)器實(shí)際狀況而定)
3、調(diào)整/usr/local/php/etc/php-fpm.conf 的相關(guān)設(shè)置
<value name=”max_children”>10</value>
<value name=”request_terminate_timeout”>60s</value>
max_children最多10個(gè)進(jìn)程,按照每個(gè)進(jìn)程20MB內(nèi)存,最多200MB。
request_terminate_timeout執(zhí)行的時(shí)間為60秒,也就是1分鐘。
#################################################
網(wǎng)站運(yùn)行環(huán)境是Nginx +php fastcgi模式的。這幾天運(yùn)行一直不穩(wěn)定,總是出錯(cuò),報(bào)502錯(cuò)誤。
今天跟以前的同事請(qǐng)教了一下,他告訴我檢查一下php-fpm的日志,那里記錄了很多有用的信息。
于是我檢查了一下,發(fā)現(xiàn)確實(shí)有很多報(bào)錯(cuò)信息:
Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200
如果和nginx.conf : worker_rlimit_nofile 65500; 不一致必須檢查,設(shè)置重啟服務(wù)
Mar 01 14:39:15.881047 [NOTICE] fpm_children_make(), line 352: child 12364 (pool default) started
Mar 01 14:39:21.715825 [NOTICE] fpm_got_signal(), line 48: received SIGCHLD
Mar 01 14:39:21.715899 [NOTICE] fpm_children_bury(), line 215: child 11947 (pool default) exited with code 0 after 175.443305 seconds from start
有的報(bào)錯(cuò)信息,就好說(shuō)了,直接上網(wǎng)查信息。
經(jīng)過(guò)搜索,最后總結(jié)出以下幾條優(yōu)化策略:
1、提升服務(wù)器的文件句柄打開(kāi)打開(kāi)
# vi /etc/security/limits.conf 加上
* soft nofile 65500
* hard nofile 65500
2、提升nginx的進(jìn)程文件打開(kāi)數(shù)
nginx.conf : worker_rlimit_nofile 65500;
3、修改php-fpm.conf文件,主要需要修改2處。
命令 ulimit -n 查看限制的打開(kāi)文件數(shù),php-fpm.conf 中的選項(xiàng)rlimit_files 確保和此數(shù)值一致。
<value name=”max_requests”>10240</value>
<value name=”rlimit_files”>65500</value>
4、
# vi /etc/sysctl.conf
底部添加
fs.file-max=65500
經(jīng)過(guò)以上修改,重啟php。/usr/local/webserver/php/sbin/php-fpm restart
在查看ulimit -n 是否生效,否則重啟服務(wù)器或者/etc/sysctl.conf、/etc/security/limits.conf的配置生效
到目前為止還沒(méi)有出現(xiàn)過(guò)以上的報(bào)錯(cuò)信息。一切運(yùn)行正常。
php技術(shù):深入探討:Nginx 502 Bad Gateway錯(cuò)誤的解決方法,轉(zhuǎn)載需保留來(lái)源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除,多謝。