解决502错误的笔记

阅读更多

使用socket方式连接Nginx优化php-fpm性能

 

TCP和unix domain socket方式对比

 

TCP是使用TCP端口连接127.0.0.1:9000

 

Socket是使用unix domain socket连接套接字/dev/shm/php-cgi.sock(很多教程使用路径/tmp,而路径/dev/shm是个tmpfs,速度比磁盘快得多

 

测试机是个1核的centos5.4,2用户并发时系统资源消耗50%左右,10用户资源就跑得很满了。

 

    2users 10users
nginx/1.2.9 + PHP 5.2.5 tcp 1060 1294
nginx/1.2.9 + PHP 5.2.5 socket 997 1487
nginx/1.2.9 + PHP 5.3.10 tcp 906 1082
nginx/1.2.9 + PHP 5.3.10 socket 880 1247

 

结论是在服务器压力不大的情况下,tcp和socket差别不大,但在压力比较满的时候,用套接字方式,效果确实比较好。

 

下面是php 5.3以上版本将TCP改成socket方式的配置方法:

 

修改php-fpm.conf(/usr/local/php/etc/php-fpm.conf)

 

 
  1. ;listen = 127.0.0.1:9000
  2. listen = /dev/shm/php-cgi.sock

 

修改nginx配置文件server段的配置,将http的方式改为socket方式

 

  1. location ~ [^/]\.php(/|$) {
  2.     #fastcgi_pass 127.0.0.1:9000;
  3.     fastcgi_pass unix:/dev/shm/php-cgi.sock;
  4.     fastcgi_index index.php;
  5.     include fastcgi.conf;
  6. }

 

重启php-fpm与nginx

 

  1. service nginx restart
  2. service php-fpm restart

 

  1. ls -al /dev/shm

 

可以看到php-cgi.sock文件unix套接字类型

 

 

 

Nginx 502 Bad Gateway的含義是請求的PHP-CGI已經執行,但是由於某種原因(一般是讀取資源的問題)沒有執行完畢而導致PHP-CGI進程終止。

    Nginx 504 Gateway Time-out的含義是所請求的網關沒有請求到,簡單來說就是沒有請求到可以執行的PHP-CGI。

    解決這兩個問題其實是需要綜合思考的,一般來說Nginx 502 Bad Gateway和php-fpm.conf的設置有關,而Nginx 504 Gateway Time-out則是與nginx.conf的設置有關。

    而正確的設置需要考慮服務器自身的性能和訪客的數量等多重因素。

    以我目前的服務器爲例子CPU是奔四1.5G的,內存1GB,CENTOS的系統,訪客大概是50人左右同時在綫。

    但是在綫的人大都需要請求PHP-CGI進行大量的信息處理,因此我將nginx.conf設置爲:

    fastcgi_connect_timeout 300s;

    fastcgi_send_timeout 300s;

    fastcgi_read_timeout 300s;

    fastcgi_buffer_size 128k;

    fastcgi_buffers 8 128k;#8 128

    fastcgi_busy_buffers_size 256k;

    fastcgi_temp_file_write_size 256k;

    fastcgi_intercept_errors on;

    這裏最主要的設置是前三條,即

    fastcgi_connect_timeout 300s;

    fastcgi_send_timeout 300s;

    fastcgi_read_timeout 300s;

    這裏規定了PHP-CGI的連接、發送和讀取的時間,300秒足夠用了,因此我的服務器很少出現504 Gateway Time-out這個錯誤。最關鍵的是php-fpm.conf的設置,這個會直接導致502 Bad Gateway和504 Gateway Time-out。

    下面我們來仔細分析一下php-fpm.conf幾個重要的參數:

    php-fpm.conf有兩個至關重要的參數,一個是”max_children”,另一個是”request_terminate_timeout”

    我的兩個設置的值一個是”40″,一個是”900″,但是這個值不是通用的,而是需要自己計算的。

    計算的方式如下:

    如果你的服務器性能足夠好,且寬帶資源足夠充足,PHP腳本沒有係循環或BUG的話你可以直接將”request_terminate_timeout”設置成0s。0s的含義是讓PHP-CGI一直執行下去而沒有時間限制。而如果你做不到這一點,也就是說你的PHP-CGI可能出現某個BUG,或者你的寬帶不夠充足或者其他的原因導致你的PHP-CGI能夠假死那麼就建議你給”request_terminate_timeout”賦一個值,這個值可以根據你服務器的性能進行設定。一般來說性能越好你可以設置越高,20分鐘 -30分鐘都可以。由於我的服務器PHP腳本需要長時間運行,有的可能會超過10分鐘因此我設置了900秒,這樣不會導致PHP-CGI死掉而出現502 Bad gateway這個錯誤。

    而”max_children”這個值又是怎麼計算出來的呢?這個值原則上是越大越好,php-cgi的進程多了就會處理的很快,排隊的請求就會很少。設置”max_children”也需要根據服務器的性能進行設定,一般來說一臺服務器正常情況下每一個php-cgi所耗費的內存在20M左右,因此我的”max_children”我設置成40個,20M*40=800M也就是說在峰值的時候所有PHP-CGI所耗內存在800M以內,低於我的有效內存1Gb。而如果我的”max_children”設置的較小,比如5-10個,那麼php-cgi就會“很累”,處理速度也很慢,等待的時間也較長。如果長時間沒有得到處理的請求就會出現504 Gateway Time-out這個錯誤,而正在處理的很累的那幾個php-cgi如果遇到了問題就會出現502 Bad gateway這個錯誤。

 

 

Linux上配置FastCGI的详细过程

Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,以事件驱动的方式编写,所以有非常好的性能,同时也是一个非常高效的反向代理、负载平衡。其拥有匹配Lighttpd的性能,同时还没有Lighttpd的内存泄漏问题,而且Lighttpd的mod_proxy也有一些问题并且很久没有更新。

因此我打算用其替代Apache应用于Linux服务器上。但是Nginx并不支持cgi方式运行,原因是可以减少因此带来的一些程序上的漏洞。那么我们必须使用FastCGI方式来执行PHP程序。

下面是我成功地配置Nginx + PHP5 FastCGI的过程

首先安装或编译Nginx

安装Nginx

源码包可以在官方主页上下载。Ubuntu 7.10可以直接通过apt安装,也可以从这里下载最新的deb包:


sudo apt-get install nginx

如果要自己编译的话,需要确保自己已经有编译器和PCRE的库(用于Nginx的rewrite模块,如果不需要这个模块可以在configure时使用./configure –without-rewrite),编译方法如下:


wget http://sysoev.ru/nginx/nginx-0.5.34.tar.gz
tar zxvf nginx-0.5.34.tar.gz
cd nginx-0.5.34
./configure #默认配置安装路径为/usr/local/nginx 可以追加--prefix=/usr设置到/usr
make && make install  # install要求有root权限

Ubuntu安装之后的文件结构大致为:

所有的配置文件都在/etc/nginx下,并且每个虚拟主机已经安排在了/etc/nginx/sites-available下

程序文件在/usr/sbin/nginx

日志放在了/var/log/nginx中

并已经在/etc/init.d/下创建了启动脚本nginx

默认的虚拟主机的目录设置在了/var/www/nginx-default

而自己利用默认配置编译的,则放在/usr/local/nginx下,以下是目录结构:


/usr/local/nginx/conf 配置目录
/usr/local/nginx/html 默认的网站根目录
/usr/local/nginx/logs 日志和pid文件目录
/usr/local/nginx/sbin 执行文件目录

下面可以启动nginx来看看效果(请确保80端口没有其他服务在使用):
Ubuntu请运行:


sudo /etc/init.d/nginx start

其他请运行:


/usr/local/nginx/sbin/nginx

然后就可以通过http://localhost/来看看效果了。

要配置nginx的自动运行,可以将/usr/local/nginx/sbin/nginx添加到/etc/rc.local中,Ubuntu可以执行


update-rc.d nginx defaults

安装PHP5

至于如何在Linux上安装PHP,有很多文章,甚至很多平台上都有现成的软件包,无需自己编译。

PHP5的CGI方式的一大优势是内置了FastCGI的支持,只需指明绑定的地址和端口参数便可以以FastCGI的方式运行,如下:

php-cgi -b 127.0.0.1:9000

如何配置其与nginx一起运行呢?

配置Nginx的PHP FastCGI

请将以下内容保存为fastcgi_params文件,保存于/usr/local/nginx/conf下(Ubuntu可保存于/etc/nginx下),他为我们的FastCGI模块设置了基本的环境变量:


#fastcgi_params
fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;
# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

请特别注意”fastcgi_script_name”一行,PHP-CGI特别需要此行信息来确定PHP文件的位置。

另外需要在PHP-CGI的配置文件(Ubuntu 上此配置文件位于/etc/php5/cgi/php.ini)中,打开cgi.fix_pathinfo选项:


cgi.fix_pathinfo=1;

这样php-cgi方能正常使用SCRIPT_FILENAME这个变量。

接下来在nginx的配置中针对php文件配置其利用FastCGI进程来执行:


server {
    index index.php;
    root  /usr/local/nginx/html;

    location ~ .*.php$ {
        include /usr/local/nginx/conf/fastcgi_params;  #请根据自己保存的路径进行设置
        fastcgi_index index.php;
        fastcgi_pass  127.0.0.1:9000; #请根据自己的FastCGI绑定的地址和端口进行配置
    }
}

通知Nginx重新载入配置:


kill -HUP `cat /usr/local/nginx/logs/nginx.pid`

Ubuntu用户可以使用init脚本:sudo /etc/init.d/nginx reload

然后启动php-cgi -b 127.0.0.1:9000

假设你在文档根目录放了index.php,并包含”phpinfo();”的内容,现在再看http://localhost/index.php便应该能看到php的调试信息了。

配置php进程

直接使用php-cgi的FastCGI运行方式有两个问题(貌似应该有解决方案,如果知道的话可以教教我):


1.如果进程崩溃,难以配置重新启动
2.单进程的效率低

因此,我们可以利用Lighttpd的spawn-fcgi来控制进程的运行。获得spawn-fcgi的方法如下:


wget http://www.lighttpd.net/download/lighttpd-1.4.18.tar.bz2 #获取Lighttpd的源码包
tar -xvjf lighttpd-1.4.18.tar.bz2
cd lighttpd-1.4.18
./configure  #编译
make
cp src/spawn-fcgi /usr/local/bin/spawn-fcgi #取出spawn-fcgi的程序

下面我们就可以使用 spawn-fcgi 来控制php-cgi的FastCGI进程了


/usr/local/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -C 5 -u www-data -g www-data -f /usr/bin/php-cgi

参数含义如下


-f  指定调用FastCGI的进程的执行程序位置,根据系统上所装的PHP的情况具体设置
-a  绑定到地址addr
-p  绑定到端口port
-s  绑定到unix socket的路径path
-C  指定产生的FastCGI的进程数,默认为5(仅用于PHP)
-P  指定产生的进程的PID文件路径
-u和-g FastCGI使用什么身份(-u 用户 -g 用户组)运行,Ubuntu下可以使用www-data,其他的根据情况配置,如nobody、apache等

然后我们可以将这行代码加入到/etc/rc.local文件底部,这样系统启动的时候也可以同时启动PHP的FastCGI进程。

 

Nginx 502错误原因和解决方法总结

一、NGINX 502错误排查
NGINX 502 Bad Gateway错误是FastCGI有问题,造成NGINX 502错误的可能性比较多。将网上找到的一些和502 Bad Gateway错误有关的问题和排查方法列一下,先从FastCGI配置入手:
1.FastCGI进程是否已经启动
2.FastCGI worker进程数是否不够
运行 netstat -anpo | grep “php-cgi” | wc -l 判断是否接近FastCGI进程,接近配置文件中设置的数值,表明worker进程数设置太少
3.FastCGI执行时间过长
根据实际情况调高以下参数值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
4.FastCGI Buffer不够
nginx和apache一样,有前端缓冲限制,可以调整缓冲参数
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
5.Proxy Buffer不够
如果你用了Proxying,调整
proxy_buffer_size   16k;
proxy_buffers    4 16k;
参见:http://www.server110.com
6.https转发配置错误
正确的配置方法
server_name www.mydomain.com;
location /myproj/repos {
set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ )
{
set $fixed_destination http$1;
}
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Destination $fixed_destination;
proxy_pass http://subversion_hosts;
}
当然,还要看你后端用的是哪种类型的FastCGI,我用过的有php-fpm,流量约为单台机器40万PV(动态页面), 现在基本上没有碰到502。

7.php脚本执行时间过长
将php-fpm.conf的0s的0s改成一个时间

二、Nginx 413错误的排查:修改上传文件大小限制

在上传时nginx返回了413错误,查看log文件,显示的错误信息是:”413 Request Entity Too Large”, 于是在网上找了下“nginx 413错误”发现需要做以下设置:
在nginx.conf增加 client_max_body_size的相关设置, 这个值默认是1m,可以增加到8m以增加提高文件大小限制;
如果运行的是php,那么还要检查php.ini,这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,这样就不会因为提交数据大小不一致出现的错误。
post_max_size = 8M
upload_max_filesize = 2M

三、Nginx 400错误排查:HTTP头/Cookie过大
今天有人汇报nginx的HTTP400错误,而且这个HTTP400错误并不是每次都会出现的,查了一下发现nginx400错误是由于request header过大,通常是由于cookie中写入了较长的字符串所引起的。
解决方法是不要在cookie里记录过多数据,如果实在需要的话可以考虑调整在nginx.conf中的client_header_buffer_size(默认1k)
若cookie太大,可能还需要调整large_client_header_buffers(默认4k),该参数说明如下:
请求行如果超过buffer,就会报HTTP 414错误(URI Too Long)
nginx接受最长的HTTP头部大小必须比其中一个buffer大,否则就会报400的HTTP错误(Bad Request)。

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行,但是由于某种原因(一般是读取资源的问题)没有执行完毕而导致PHP-CGI进程终止。
Nginx 504 Gateway Time-out的含义是所请求的网关没有请求到,简单来说就是没有请求到可以执行的PHP-CGI。

解决这两个问题其实是需要综合思考的,一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关,而Nginx 504 Gateway Time-out则是与nginx.conf的设置有关。
而正确的设置需要考虑服务器自身的性能和访客的数量等多重因素。
以我目前的服务器为例子CPU是奔四1.5G的,内存1GB,CENTOS的系统,访客大概是50人左右同时在线。
但是在线的人大都需要请求PHP-CGI进行大量的信息处理,因此我将nginx.conf设置为:
fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;
fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;#8 128
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;
这里最主要的设置是前三条,即
fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;
这里规定了PHP-CGI的连接、发送和读取的时间,300秒足够用了,因此我的服务器很少出现504 Gateway Time-out这个错误。最关键的是php-fpm.conf的设置,这个会直接导致502 Bad Gateway和504 Gateway Time-out。
下面我们来仔细分析一下php-fpm.conf几个重要的参数:
php-fpm.conf有两个至关重要的参数,一个是”max_children”,另一个是”request_terminate_timeout”
我的两个设置的值一个是”40″,一个是”900″,但是这个值不是通用的,而是需要自己计算的。
计算的方式如下:
如果你的服务器性能足够好,且宽带资源足够充足,PHP脚本没有系循环或BUG的话你可以直接将”request_terminate_timeout”设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点,也就是说你的PHP-CGI可能出现某个BUG,或者你的宽带不够充足或者其他的原因导致你的PHP-CGI能够假死那么就建议你给”request_terminate_timeout”赋一个值,这个值可以根据你服务器的性能进行设定。一般来说性能越好你可以设置越高,20分钟-30分钟都可以。由于我的服务器PHP脚本需要长时间运行,有的可能会超过10分钟因此我设置了900秒,这样不会导致PHP-CGI死掉而出现502 Bad gateway这个错误。

而”max_children”这个值又是怎么计算出来的呢?这个值原则上是越大越好,php-cgi的进程多了就会处理的很快,排队的请求就会很少。设置”max_children”也需要根据服务器的性能进行设定,一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右,因此我的”max_children”我设置成40个,20M*40=800M也就是说在峰值的时候所有PHP-CGI所耗内存在800M以内,低于我的有效内存1Gb。而如果我的”max_children”设置的较小,比如5-10个,那么php-cgi就会“很累”,处理速度也很慢,等待的时间也较长。如果长时间没有得到处理的请求就会出现504 Gateway Time-out这个错误,而正在处理的很累的那几个php-cgi如果遇到了问题就会出现502 Bad gateway这个错误。

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

nginx中配置php fastcgi组解决莫名其妙的502 Bad Gateway错误

一般nginx搭配php都采用这样的方式:

location ~ .php$ {
proxy_pass        http://localhost:9000;
fastcgi_param   SCRIPT_FILENAME   /data/_hongdou$fastcgi_script_name;
include        fastcgi_params;
}

这个方式只能连接到一组spawn-fcgi开启的fastcgi,在服务器负载稍高时常常出现502 bad gateway错误。

起先怀疑这是php-cgi的进程开得太少,增加后仍然有反映时常有错,偶然间发现php-cgi会报出这样的错误:

zend_mm_heap corrupted

看来是php-cgi在执行某些代码时有问题,以致于该线程中止。

在服务器上可能还会看到php-cgi进程在不断变少,估计是出现错误的php-cgi的进程自动退出了。

php的问题总是不太容易能解决,所以在nginx方面想想办法,nginx的好处是它总是能爆出一些稀奇古怪的做法出来。

在nginx的proxy中,规避莫名其妙错误的办法无非是proxy到一个upstream的服务器组中,然后配置 proxy_next_upstream,让nginx遇到某种错误码时,自动跳到下一个后端上。这样,应用服务器即使不稳定,但是在nginx后面就变成了稳定服务。想到nginx的fastcgi和proxy是一路东西,所以proxy能用的经验,移植到fastcgi也能跑得起来。

照着这个思路,用spawn-fcgi多开同样一组php进程,所不同的仅仅是端口:

spawn-fcgi -a 127.0.0.1 -p 9000 -u nobody -f php-cgi -C 100
spawn-fcgi -a 127.0.0.1 -p 9001 -u nobody -f php-cgi -C 100

然后把fastcgi的这段配置改成用upstream的方式:

upstream backend {
server 127.0.0.1:9000;
server 127.0.0.1:9001;
}

location ~ .php$ {
fastcgi_pass        backend;
fastcgi_param   SCRIPT_FILENAME   /data/_hongdou$fastcgi_script_name;
include        fastcgi_params;
}

检查配置结果正确,能跑起来;同时在服务器上netstat -n|grep 9000和grep 9001都有记录,证明连接无误;在前台查阅页面,一切运行正常。

这个配置是最简单的配置,既然能连接上upstream,那么很显然upstream的一些东西都可以拿来用,比如ip_hash、weight、max_fails等。

这样的配置在单机下不知能不能共享session,没有测试,如果有问题,可以加上ip_hash,或者配置php把session存进memcached中。

然后就是fastcgi_next_upstream的配置,nginx wiki中没有介绍到这个配置,查了一下,在nginx的CHANGES中有提到,而且出生年月是和proxy_next_upstream一样的。既然如此,那就照proxy_next_upstream一样配吧。一般按默认的值error timeout就可以工作,因为php出现502错误的异常是返回的500错误,所以我把fastcgi_next_upstream定为:

fastcgi_next_upstream error timeout invalid_header http_500;

通过这个配置,就可以基本杜绝任何时常性的500错误,出问题的几率会变小很多,如果客户反映仍然激烈,那么就多增加几组fastcgi进程。

以上配置能够杜绝由于php所引起的“莫名其妙”的时常性的502错误,同时可使nginx搭配php比从前方式更为强悍。假如nginx还是返回502错误,那这次就一定是出现服务器挂掉或其它严重问题的了。

 

 

Nginx 499错误的原因及解决方法
    打开Nginx的access.log发现在最后一次的提交是出现了HTTP1.1 499 0 -这样的错误,在百度搜索nginx 499错误,结果都是说客户端主动断开了连接。
    但经过我的测试这显然不是客户端的问题,因为使用端口+IP直接访问后端服务器不存在此问题,后来测试nginx发现如果两次提交post过快就会出现499的情况,看来是nginx认为是不安全的连接,主动拒绝了客户端的连接.

    但搜索相关问题一直找不到解决方法,最后终于在google上搜索到一英文论坛上有关于此错误的解决方法:
proxy_ignore_client_abort on;
Don’t know if this is safe.
    就是说要配置参数 proxy_ignore_client_abort on;
    表示代理服务端不要主要主动关闭客户端连接。

    以此配置重启nginx,问题果然得到解决。只是安全方面稍有欠缺,但比总是出现找不到服务器好多了。

    还有一种原因是 我后来测试发现 确实是客户端关闭了连接,或者说连接超时 ,无论你设置多少超时时间多没用 原来是php进程不够用了 改善一下php进程数 问题解决 默认测试环境才开5个子进程。

你可能感兴趣的:(解决502错误的笔记)