亚洲在线久爱草,狠狠天天香蕉网,天天搞日日干久草,伊人亚洲日本欧美

為了賬號安全,請及時綁定郵箱和手機立即綁定
已解決430363個問題,去搜搜看,總會有你想問的

當nginx顯示502 Bad Gateway錯誤,如何實現用戶無感知的自動重啟php-fpm

當nginx顯示502 Bad Gateway錯誤,如何實現用戶無感知的自動重啟php-fpm

慕森王 2019-04-14 11:23:59
最近nginx間隙性的出現502錯誤,如何實現自動重啟php-fpm呢想到的解決方案1、使用crontab定時執行shell腳本,出現錯誤后重啟(每5秒定時執行)2、使用nohup,shell腳本后臺執行示例腳本#!/bin/bashwhile:doURL="http://192.168.1.30"RESULT=`curl-m10-I-s$URL|grep"HTTP/1.1502"`if[-n"$RESULT"];then/etc/init.d/php-fpmrestartfisleep5done3、編寫nginx模塊,通過條件執行shell腳本能想到的也就是這幾種了,感覺這幾種方案都不太好,誰有更好的解決方案?
查看完整描述

2 回答

?
縹緲止盈

TA貢獻2041條經驗 獲得超4個贊

受到fastcgi_next_upstream這個參數的啟發,使用PHP-FPM線程池的概念,可以完美的解決502錯誤(http_502是沒有的)
http里面的配置
upstreamphp_fpm_sock{
serverunix:/dev/shm/php-fpm.socket;
serverunix:/dev/shm/php-fpm-b.socket;
serverunix:/dev/shm/php-fpm-c.socket;
}
fastcgi_next_upstreamerrortimeoutinvalid_headerhttp_503http_500;
server里面fastcgi_pass配置
location~*\.php${
fastcgi_pass**unix:php_fpm_sock;**
fastcgi_indexindex.php;
client_max_body_size50M;
client_body_temp_path/data/www/tmp;
fastcgi_paramSCRIPT_FILENAME$document_root$fastcgi_script_name;
includefastcgi.conf;
includefastcgi_params;
}
php-fpm的配置
#/etc/php-fpm.conf文件包含多個配置文件
include=/etc/php-fpm.d/*.conf
#/etc/php-fpm.d/目錄
www-a.conf
www-b.conf
www-c.conf
#配置,三個文件這里不一致,分別對應
#Startanewpoolnamedwww-a
[www-a]
listen=/dev/shm/php-fpm.socket
ps-ef查看
www1799631539012:13?00:00:51php-fpm:poolwww-b
www1799931539012:13?00:00:48php-fpm:poolwww-a
www1801031539012:14?00:00:46php-fpm:poolwww-b
www1806331539012:25?00:00:42php-fpm:poolwww-c
www1815331539012:47?00:00:34php-fpm:poolwww-c
www1815431539112:47?00:00:37php-fpm:poolwww-a
www1818531539012:55?00:00:29php-fpm:poolwww-c
www1831331539013:24?00:00:10php-fpm:poolwww-a
1、啟動的各個PHP-FPM線程池,只要不都掛掉,nginx就可以正常執行PHP,如果有的異常退出了,基本也不影響網站運行2、fastcgi_next_upstream那行的參數,不需要加http_502,實際你也加不上去的3、原有的每段類似這種location~\.php${}代碼都需要對fastcgi_pass這行根據示例改造
                            
查看完整回答
反對 回復 2019-04-14
?
慕后森

TA貢獻1802條經驗 獲得超5個贊

Nginx可以配置fastcgi_next_upstream實現故障轉移,比如:
fastcgi_next_upstreamerrortimeoutinvalid_headerhttp_500http_503;
后端PHP-FPM返回error、timeout等信息則自動切換到upstream里的下一臺PHP-FPM應用服務器。
個人覺得最好還是找出PHP-FPM工作進程崩潰的原因,是代碼問題,還是系統資源不足導致響應超時。注意兩點,一是不要在PHP-FPM里執行耗時太長或不確定的代碼,比如curl發出網絡請求。二是PHP-FPM工作進程不是越多越好,個人認為,PHP-FPM工作進程數,設置為2倍CPU核心數就足夠了。畢竟,Nginx和MySQL以及系統同樣要消耗CPU。根據服務器內存來設置PHP-FPM進程數是非常不合理的,把內存分配給MySQL、Memcached這些服務顯然更合適,過多的PHP-FPM進程反而會增加CPU上下文切換的開銷。
                            
查看完整回答
反對 回復 2019-04-14
  • 2 回答
  • 0 關注
  • 532 瀏覽
慕課專欄
更多

添加回答

舉報

0/150
提交
取消
微信客服

購課補貼
聯系客服咨詢優惠詳情

幫助反饋 APP下載

慕課網APP
您的移動學習伙伴

公眾號

掃描二維碼
關注慕課網微信公眾號