Nginx + PHP 502 超时,靠!!

nginx+php 出现 502 bad gateway,一般这都不是 nginx 的问题,而是由于 fastcgi 或者 php 的问题导致的,常见的有以下几种。

  1. php.inimemory_limit 过小(如果有个别 php 程序进程需要占用极大内存时这个必须注意)

  2. php-fpm.confmax_children 或者 max_requests 设置不合理(设置过小会因为没有足够的cgi进程处理请求,设置过大会出现一会儿有响应正常,一会儿等很久才有响应的情况,一般情况下 children 按 照内存计算,比如说 1G 设置 642G 128。这个根据实际情况自行调整。另外查看当前的 PHP FastCGI 进程数是否够用的命令为: netstat -anpo | grep "php-cgi" | wc -l 如果实际使用的 FastCGI进程数 接近预设的 FastCGI进程数,那么,说明FastCGI进程数 不够用,需要增大。)

  3. 查看 nginx 错误日志,发现 pstream sent too big header while reading response headerfrom upstream ,则检查 client head bufferfastcgi buffer size是否过小,可设置为 32K

  4. php 程序执行时间过长而超时,检查 nginxfastcgi 中各种 timeout 设置。(nginx 中的 fastcgi_connect_timeout 300;fastcgi_send_timeout 300fastcgi_read_timeout300;keepalive_timeout php-fpm 中的 request_terminate_timeout,php.ini 中的 max_execution_time

  5. php-fpm 有一个参数 max_requests ,该参数指明了每个children最多处理多少个请求后便会被关闭。在大量处理请求下,如果该值设置过小会导致 children频繁的自杀和建立而浪费 大量时间,若所有的children差不多都在这个时候自杀,则重建前将没有children响应请求,于是出现502 。可以将该值设置大一些或者是0[无限]。

以上差不多是比较常见的502的问题原因以及解决办法,其实解决问题的最好的方式还是自己去看nginx和fastcgi的errorlog。

最后借用网上的万金油说法做个总结: php-cgi进程数不够用、php执行时间长、或者是php-cgi进程死掉,都会出现502错误。

502 错误是所有用 nginx 跑 php 的运维人员不愿意看见的

nginx 出现 502 有很多原因,但大部分原因可以归结为资源数量不够用 , 也就是说后端 php-fpm 处理有问题, nginx 将正确的客户端请求发给了后端的 php-fpm 进程,但是因为 php-fpm 进程的问题导致不能正确解析 php 代码,最终返回给了客户端 502 错误。

服务器出现 502 的原因是连接超时 我们向服务器发送请求 由于服务器当前链接太多,导致服务器方面无法给于正常的响应 , 产生此类报错

因此如果你服务器并发量非常大,那只能先增加机器,然后按以下方式优化会取得更好效果 ; 但如果你并发不大却出现 502 ,一般都可以归结为配置问题,脚本超时问题。

1.php-fpm 进程数不够用

使用 netstat -napo |grep “php-fpm” | wc -l 查看一下当前 fastcgi 进程个数,如果个数接近 conf 里配置的上限,就需要调高进程数。

但也不能无休止调高,可以根据服务器内存情况,可以把 php-fpm 子进程数调到 100 或以上,在 4G 内存的服务器上 200 就可以。

  1. 调高调高 linux 内核打开文件数量

可以使用这些命令 ( 必须是 root 帐号 )

echo ‘ulimit -HSn 65536’>> /etc/profile

echo ‘ulimit -HSn 65536’>> /etc/rc.local

source /etc/profile

  1. 脚本执行时间超时

如果脚本因为某种原因长时间等待不返回 ,导致新来的请求不能得到处理,可以适当调小如下配置。

nginx.conf 里面主要是如下

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

php-fpm.conf 里如要是如下

request_terminate_timeout =10s

  1. 缓存设置比较小

修改或增加配置到 nginx.conf

proxy_buffer_size 64k;
proxy_buffers 512k;
proxy_busy_buffers_size 128k;

  1. recv()failed (104: Connection reset by peer) while reading response header fromupstream

可能的原因机房网络丢包或者机房有硬件防火墙禁止访问该域名

但最重要的是程序里要设置好超时,不要使用 php-fpm 的 request_terminate_timeout ,

最好设成 request_terminate_timeout=0;

因为这个参数会直接杀掉 php 进程,然后重启 php 进程,这样前端 nginx 就会返回 104: Connection reset by peer 。这个过程是很慢,总体感觉就是网站很卡。

May 01 10:50:58.044162[WARNING] [pool www] child 4074, script’/usr/local/nginx/html/quancha/sameip/detail.php’ execution timed out(15.129933 sec), terminating
May 01 10:50:58.045725 [WARNING] [pool www] child 4074 exited on signal 15SIGTERM after 90.227060 seconds from start
May 01 10:50:58.046818 [NOTICE] [pool www] child 4082 started

说一千道一万最重要的就是程序里控制好超时, gethostbyname 、 curl 、 file_get_contents 等函数的都要设置超时时间。

另一个就是多说,这个东西是增加了网站的交互性,但是使用的多了反应就慢了,如果你网站超时且使用了多说是,可以关闭它。

6、自己遇到502的解决办法:
调整增大php 和Nginx 的backlog数。

PHP-FPM 高负载的解决办法
Postedon 2011/09/02

这里只是介绍了 php-fpm 的优化方法的,但一般情况下和 nginx 组合使用的时候,单独优化其中一项的话,作用不是特别的大,同时还需要对 nginx 进行优化. nginx 的做法方法参考: http://blog.haohtml.com/archives/6213 . 上面的优化前和优化后的图,看得出前后差距还是特别的大的.

导致 nginx 502 bad gateway 的PHP-CGI(FASTCGI)

NGINX 频爆 502 BAD GATEWAY 的错误,看了网上的教程,仍没有彻底解决。
目前我总结的解决 502 BAD GATEWAY 的方式有: 1. 视服务器的性能,在 php-fmp.conf 里增加 max_children 的值,我目前用的

用 reload 参数定时重载 php-fpm 。这个主要原因是 php 脚本执行时间过长造成的,重载 php-fpm 能杜绝这个问题。如何彻底解决 php-cgi 脚本占用大量内存从而导致 502 错误的产生还值得进一步探讨,目前该做法不失为一种好办法。
具体的做法是,用 crontab 让 php-fpm 平滑重启,从而不影响 PHP 脚本的运行。
/10 * * * /usr/local/php/sbin/php-fpm reload

=================== 优化设置 =========================

When you running a highload websitewith PHP-FPM via FastCGI, the following tips may be useful to you : )

如果您高负载网站使用 PHP-FPM 管理 FastCGI ,这些技巧也许对您有用: )

1.Compile PHP’s modules as less as possible, the simple the best (fast);

  1. 尽量少安装 PHP 模块,最简单是最好(快)的

  2. Increas PHP FastCGI child number to 100 and even more.Sometime, 200 is OK! ( On 4GB memory server);

  3. 把您的 PHP FastCGI 子进程数调到 100 或以上,在 4G 内存的服务器上 200 就可以
    注:我的 1g 测试机,开 64 个是最好的,建议使用压力测试获取最佳值

3.Using SOCKET PHP FastCGI, and put into /dev/shm on Linux;
3. 使用 socket 连接 FastCGI , linux 操作系统可以放在 /dev/shm 中
注:在 php-fpm.cnf 里设置 <valuename=”listen_address”>/tmp/nginx.socket 就可以通过 socket 连接 FastCGI 了, /dev/shm 是内存文件系统,放在内存中肯定会快了 . 记得这时也要在 nginx 里的配置里进行修改,保持一致.

location~ .*.(php|php5)?$

{

将 Nginx 与 FastCGI 的通信方式由 TCP 改为 UnixSocket 。 TCP 在高并发访问下比 UnixSocket 稳定,但 Unix Socket 速度要比 TCP 快。
fastcgi_pass unix:/tmp/php-cgi.sock;

#fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fcgi.conf;

}

  1. Increase Linux “max open files”, using the following command(must be root):

echo ‘ulimit -HSn 65536′>> /etc/profile

echo ‘ulimit -HSn 65536 >> /etc/rc.local

source /etc/profile

  1. 调高 linux 内核打开文件数量,可以使用这些命令 ( 必须是 root 帐号
    )

echo ‘ulimit -HSn 65536′ >> /etc/profile

echo ‘ulimit -HSn 65536′ >> /etc/rc.local

source /etc/profile

注:我是修改 /etc/rc.local ,加入 ulimit -SHn 51200 的
5.Increase PHP-FPM open file description rlimit:

vi /path/to/php-fpm.conf

Find “1024”

Change 1024 to 4096 or higher number.

Restart PHP-FPM.

  1. 增加 PHP-FPM 打开文件描述符的限制
    :

vi /path/to/php-fpm.conf

找到
“1024”

把 1024 更改为 4096 或者更高
.

重启 PHP-FPM.
6. Using PHP code accelerator,e.g eAccelerator, XCache. And set “cache_dir” to /dev/shm on Linux.
6. 使用 php 代码加速器,例如 eAccelerator, XCache. 在 linux 平台上可以把 cache_dir 指向 /dev/shm

猜你喜欢

转载自blog.csdn.net/Webben/article/details/83150945