为了账号安全,请及时绑定邮箱和手机立即绑定

当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 关注
  • 514 浏览
慕课专栏
更多

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信