502 Bad Gateway(PHP的角度来分析)

第一点:   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加一个超时参数。

$ctx = stream_context_create(array(
    ‘http‘ => array(
        ‘timeout‘ => 10    //设置一个超时时间,单位为秒
    )
));
file_get_contents($str, 0, $ctx);

第二点:max_requests参数配置不当,可能会引起间歇性502错误:
pm.max_requests = 1000;
设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为 ’0′ 则一直接受请求. 等同于 PHP_FCGI_MAX_REQUESTS 环境变量. 默认值: 0.
这段配置的意思是,当一个 PHP-CGI 进程处理的请求数累积到 1000 个后,自动重启该进程。

但是为什么要重启进程呢?
一般在项目中,我们多多少少都会用到一些 PHP 的第三方库,这些第三方库经常存在内存泄漏问题,如果不定期重启 PHP-CGI 进程,势必造成内存使用量不断增长。因此 PHP-FPM 作为 PHP-CGI 的管理器,提供了这么一项监控功能,对请求达到指定次数的 PHP-CGI 进程进行重启,保证内存使用量不增长。
正是因为这个机制,在高并发的站点中,经常导致 502 错误,我猜测原因是 PHP-FPM 对从 NGINX 过来的请求队列没处理好。不过我目前用的还是 PHP 5.3.2,不知道在 PHP 5.3.3 中是否还存在这个问题。
目前我们的解决方法是,把这个值尽量设置大些,尽可能减少 PHP-CGI 重新 SPAWN(产卵) 的次数,同时也能提高总体性能。在我们自己实际的生产环境中发现,内存泄漏并不明显,因此我们将这个值设置得非常大(204800)。大家要根据自己的实际情况设置这个值,不能盲目地加大。
话说回来,这套机制目的只为保证 PHP-CGI 不过分地占用内存,为何不通过检测内存的方式来处理呢?我非常认同高春辉所说的,通过设置进程的峰值内在占用量来重启 PHP-CGI 进程,会是更好的一个解决方案。

综上,针对fpm重启的观点,本人认为可以利用 在fpm中进程池的概览,我们可以设置多个进程池;

[www]user = wwwgroup = wwwlisten = 127.0.0.1:9001pm = dynamicpm.max_children = 500pm.start_servers = 200pm.min_spare_servers = 100pm.max_spare_servers = 300

[www]user = wwwgroup = wwwlisten = 127.0.0.1:9000pm = dynamicpm.max_children = 500pm.start_servers = 200pm.min_spare_servers = 100pm.max_spare_servers = 300

nginx 配置

机器A nginx.conf配置

#在http 区域中增加:

upstream backend{
      server  127.0.0.1:9000 weight=1;
      server  127.0.0.1:9001 weight=2;
      keepalive 3072;
}

#在server 内如下配置

location ~ .*\.php
 {
            fastcgi_pass backend;
            fastcgi_index index.php;
            include fastcgi.conf;
  }

时间: 2024-10-12 08:58:02

502 Bad Gateway(PHP的角度来分析)的相关文章

nginx 502 Bad Gateway的解决方法总结

昨天自己的机器老提示502 Bad Gateway错误提示,下面小编来给大家总结关于nginx出现502 Bad Gateway的解决方法,有碰到此类问题的朋友可参考. 发生原因 1.PHP FastCGI进程数不够用 当网站并发访问巨大时,php fastcgi的进程数不有一定的保障,因为cgi是单线程多进程工作的,也就是说cgi需要处理完一个页面后再继续下一个页面.如果进程数不够,当访问巨大的时候,cgi按排队处理之前的请求,之后的请求只有被放弃.这个时候nginx就会不时的出现502错误.

502 Bad Gateway

502 Bad Gateway The proxy server received an invalid response from an upstream server. Sorry for the inconvenience.Please report this message and include the following information to us.Thank you very much! URL: http://y.baidu.com/index.html Server:

502 Bad Gateway深究

早上收到502报警,设置的报警规则是502错误两分钟超过500就报警. 排障流程: 日志分析系统报障-->查看日志系统日志-->nginx错误日志-->php错误日志-->php-fpm.log日志 在日志分析系统里面看到产生502报警的机器只有一台xxx.xxx.xxx.170,客户端IP也只有一个,说明不是大规模故障. 连接到170服务器查看nginx错误日志,看到Connection reset by peer,连接被对方重置,说明php关掉了这个连接 2016/12/29

Nginx 502/504 Gateway time-out错误完美解决方案【转发】

在安装完Nginx+PHP-fpm+Mysql后,跑PHP的应用会经常出现504 Gateway Time-out 或者502 Bad Gateway的情况. Nginx 504 Gateway Time-out 的含义是所请求的网关没有请求到,简单来说就是没有请求到可以执行的 PHP-CGI.这种情况可能是由于 nginx 默认的 fastcgi 进程响应的缓冲区太小造成的, 这将导致 fastcgi 进程被挂起, 如果你的 fastcgi 服务对这个挂起处理的不好, 那么最后就极有可能导致 

nginx 502 Bad Gateway 错误问题收集

nginx 502 Bad Gateway 错误问题收集 (2010-11-18 13:51:37) 转载▼ 标签: 杂谈 分类: 工作 nginx 502 Bad Gateway 错误问题收集 因为,nginx和lighttpd的文档真的很少,更不用说中文文档了,所以收集一些和502有关的错误在这里,保留来源地址,建议看来源地址的内容. 502是FastCGI出现问题,所以从FastCGI配置入手. 1.请检查你的FastCGI进程是否启动 2.FastCGI进程不够使用请通过执行 netst

nginx 502 bad gateway 问题处理集锦

一般看来, 这种情况可能是由于nginx默认的fastcgi进程响应的缓冲区太小造成的, 这将导致fastcgi进程被挂起, 如果你的fastcgi服务对这个挂起处理的不好, 那么最后就极有可能导致504 Gateway Time-out现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百K默认的fastcgi进程响应的缓冲区是8K, 我们可以设置大点 在nginx.conf里, 加入: fastcgi_buffers 8 128k 这表示设置fastcgi缓冲区为8×128

LNMP : 502 Bad Gateway 解决小记,真正的原因

网站搬迁到新的服务器,原先一直都是LAMP,现在改为LNMP. 将重写文件 htaccess改成 nginx的 conf.放到了网站,可只能打开首页,其他重写页面一打开都是不停的加载. 加载等待几十分钟之后会提示 502 Bad Gateway! -- 后来逐一排查,排查到重写规则是没有问题,程序是没有问题,原因出在了数据库连接. -- 排查到最后的原因居然是数据库连接地址 写成了127.0.0.1,改成localhost 之后一切正常. 写到这里 LNMP 网站终于搬迁完毕,原因出人意外. b

Nginx 502 bad gateway错误解决思路

当网站打开遇到Nginx 502 bad gateway的错误,造成这种错误的原因有很多,下面分别解析nginx常见的502错误. 1.nginx配置文件错误 因为nginx找不到php-fpm了,所以报错,一般是fastcgi_pass后面的路径配置错误了,后面可以是socket或者是ip:port 解决方案: [[email protected] ~]# vim/usr/local/nginx/conf/vhosts/www.conf server {    listen 80;    se

Nginx 502 Bad Gateway 错误的原因及解决方法

http://my.oschina.net/zhouyuan/blog/118708 刚才在调试程序的时候,居然服务器502错误,昨天晚上也发生了,好像我没有做非常规的操作. 然后网上寻找了下答案, 把一些原因及解决方法汇总一下,以防生产环境下的502  会有好多种情况出现502错误,下面我们分情况来说一下. 一.fastcgi缓冲区设置过小 出现错误,首先要查找nginx的日志文件,目录为/var/log/nginx,在日志中发现了如下错误. 2013/01/17 13:33:47 [erro