Archive for 五月, 2011

1.请检查你的FastCGI进程是否启动
2.FastCGI进程不够使用
请通过执行 netstat -anpo | grep "php-cgi" | wc -l 判断,是否接近你启动的FastCGI进程,接近你的设置,表示进程不够
来源:http://blog.s135.com/post/361.htm
3.执行超时
请把
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
这几项的值调高
来源:http://blog.s135.com/post/361.htm
4.FastCGI缓冲不够
nginx和apache一样,有前端缓冲限制
请把
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
这几项的值调高
来源:http://www.hiadmin.com/nginx-502-gateway-error一例/
5.Proxy缓冲不够
如果你使用了Proxying,请把
proxy_buffer_size 16k;
proxy_buffers 4 16k;
这几项的值调高
来源:http://www.ruby-forum.com/topic/169040
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;
}
来源:http://www.ruby-forum.com/topic/173455
7.php脚本执行时间过长
将php-fpm.conf的<value name="request_terminate_timeout">0s</value>的0s改成一个时间

8.Nginx 413错误的排查:修改上传文件大小限制
在上传时nginx返回了413错误,查看log文件,显示的错误信息是:”413 Request Entity Too Large”, 于是在网上找了下“nginx413错误”发现需要做以下设置:
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
9.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)。

10.参数都有所调整.目的是解决代理过程中出现的一些502 499错误

user www www;
worker_processes 4;
# [ debug | info | notice | warn | error | crit ]
error_log /usr/local/webserver/nginx/logs/nginx_error.log crit;
pid /usr/local/webserver/nginx/nginx.pid;
#Specifies the value for maximum file descriptors that can be opened by this process.
worker_rlimit_nofile 51200;
events
{
use epoll;
worker_connections 51200;
}
http
{
include mime.types;
default_type application/octet-stream;
source_charset GB2312;
server_names_hash_bucket_size 256;
client_header_buffer_size 256k;
large_client_header_buffers 4 256k;
#size limits
client_max_body_size 50m;
client_body_buffer_size 256k;
client_header_timeout 3m;
client_body_timeout 3m;
send_timeout 3m;
#参数都有所调整.目的是解决代理过程中出现的一些502 499错误
sendfile on;
tcp_nopush on;
keepalive_timeout 120; #参数加大,以解决做代理时502错误
tcp_nodelay on;
include vhosts/upstream.conf;
include vhosts/bbs.linuxtone.conf;
}

server
{
listen 80;
server_name bbs.linuxtone.conf;
charset GB2312;
index index.html index.htm;
root /date/wwwroot/linuxtone/;
location ~ ^/NginxStatus/ {
stub_status on;
access_log off;
}
location / {
root /date/wwwroot/linuxtone/;
proxy_redirect off ;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 50m;
client_body_buffer_size 256k;
proxy_connect_timeout 30;
proxy_send_timeout 30;
proxy_read_timeout 60;
proxy_buffer_size 256k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_pass http://bbs.linuxtone.com;
}

 

大内存可以把以下参数调大,可有效减少502错误



php-fpm中主要修改参数

<value name="max_children">128</value> //每一个消耗大约20M内存,根据内存大小设置

<value name="max_requests">1024</value> //每个max_children进程若超过这个数目,就自动杀死,以后用到会自动重建。一般设置1000左右。

<value name="request_terminate_timeout">0s</value> //如果你的服务器性能足够好,且宽带资源足够充足,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这个错误。



nginx中主要修改参数

fastcgi_connect_timeout 1800;

fastcgi_send_timeout 1800;

fastcgi_read_timeout 1800;

fastcgi_buffer_size 1024k;

fastcgi_buffers 32 1024k;

fastcgi_busy_buffers_size 2048k;

fastcgi_temp_file_write_size 2048k;

注:两个1024k值必须相等,否则报错



以下是默认参数

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

fastcgi_buffer_size 64k;

fastcgi_buffers 4 64k;

fastcgi_busy_buffers_size 128k;

fastcgi_temp_file_write_size 128k;

————————————————————————————————-

[ 文章作者:韦少乾 转载请注明原文链接:http://mven.cn/nginx-502-504/ ]

一、错误提示说明:

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的设置有关。

php-fpm.conf有两个至关重要的参数,一个是”max_children”,另一个是”request_terminate_timeout” ,但是这个值不是通用的,而是需要自己计算的。

 

计算的方式如下:

如果你的服务器性能足够好,且宽带资源足够充足,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提示502和504错误的临时解决办法是:

1、调整php-fpm.conf的相关设置:

<value name=”max_children”>32</value>

<value name=”request_terminate_timeout”>30s</value>

2、调整nginx.conf的相关设置:

fastcgi_connect_timeout 600;

fastcgi_send_timeout 600;

fastcgi_read_timeout 600;

fastcgi_buffer_size 256k;

fastcgi_buffers 16 256k;

fastcgi_busy_buffers_size 512k;

fastcgi_temp_file_write_size 512k;

四、终级解决方案:

标题3中所示的解决方案只能临时解决问题,而如果网站的访问量确实非常非常大,而Nginx+FastCGI只能对处理瞬间或短时间内的高并发有很好的效果,所以目前唯一的终极解决方案是:定时平滑重启php-cgi。

具体配置如下:

1、写一个非常简单的脚本:

#vi /home/www/scripts/php-fpm.sh

内容如下:

#!/bin/bash

# This script run at */1

/usr/local/php/sbin/php-fpm reload

2、将脚本添加至计划任务:

#crontab -e

内容如下:

*/1 * * * * /home/www/scripts/php-fpm.sh

注:为了省事起见,也可以不写脚本,直接在crontab里写入php-fpm的平滑重启命令。

原创文章,转载请注明:

转载自韦少乾[赵丙良] – 服务器系统架构

 

一、TCP握手协议

在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。

第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;

第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;

第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

完成三次握手,客户端与服务器开始传送数据,在上述过程中,还有一些重要的概念:

未连接队列:在三次握手协议中,服务器维护一个未连接队列,该队列为每个客户端的SYN包(syn=j)开设一个条目,该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态,当服务器收到客户的确认包时,删除该条目,服务器进入ESTABLISHED状态。
Backlog参数:表示未连接队列的最大容纳数目。

SYN-ACK 重传次数 服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重传,等待一段时间仍未收到客户确认包,进行第二次重传,如果重传次数超过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。注意,每次重传等待的时间不一定相同。

半连接存活时间:是指半连接队列的条目存活的最长时间,也即服务从收到SYN包到确认这个报文无效的最长时间,该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。

 

Web服务器在用着nginx,在日志中偶尔会看到有499这个错误。开始没想明白到底是什么意思,在Twitter上提问也没有得到答案。日志如下:

61.135.249.220 – – [02/Oct/2009:10:28:21 +0000] “GET /subject/93390/ HTTP/1.1″ 499 0 “-” “Mozilla/5.0 (compatible; YoudaoBot/1.0; http://www.youdao.com/help/webmaster/spider/; )”

61.135.249.216 – – [02/Oct/2009:10:30:08 +0000] “GET /subject/476083/ HTTP/1.1″ 499 0 “-” “Mozilla/5.0 (compatible; YoudaoBot/1.0; http://www.youdao.com/help/webmaster/spider/; )”

rfc2616中,400~500间的错误码仅定义到了417,所以499应该是nginx自己定义的。后来想到读读nginx代码,疑问立解。

在nginx源码中grep一下499(现在看源码习惯用grep大法),得到如下结果:

nginx-special-response

找到src/http/ngx_http_special_response.c 这个文件,里面定义了不少http错误码以及相应的返回。注意到有下面这样的注释:

nginx-special-codes

可以看到,499对应的是 “client has closed connection”。这很有可能是因为服务器端处理的时间过长,客户端“不耐烦”了。要解决此问题,就需要在程序上面做些优化了。

除了499,nginx还定义了495/496/497/498 这几个Status Codes,相应的意义也在上面的注释中可以看到。开源的东西,可以随时翻看源码,这一点很棒。

来源

GFS(Google File System): http://www.codechina.org/doc/google/gfs-paper/
MogileFS: http://www.danga.com/mogilefs
Hadoop/HDFS: http://hadoop.apache.org/core
KFS(Kosmos Distributed File System): http://kosmosfs.sourceforge.net
NDFS(Nutch Distributed File System):http://lucene.apache.org/nutch/,http://wiki.apache.org/nutch/NutchDistributedFileSystem
Gluster(Gluster File System): http://www.gluster.org
Coda(Coda File System): http://www.coda.cs.cmu.edu/
Global(Red Hat Global File System Redhat并购): http://www.redhat.com/gfs
Lustre(Lustre File System Sun并购): http://www.lustre.org
PVFS(Parallel Virtual File System,非开源): http://www.parl.clemson.edu/pvfs
GPFS(IBM General Parallel File System, 非开源): http://www-03.ibm.com/systems/clusters/software/gpfs
OpenAFS(Open Andrew File System IBM): http://www.openafs.org
XFS(SGI, 不算分布式文件系统): http://oss.sgi.com/projects/xfs
MOSIX: http://www.mosix.org

还有一个国内牛人写的
FastDFS一个高效的分布式文件系统 http://fastdfs.zhan.cn.yahoo.com/

参考:
http://www.bitscn.com/linux/network_manage/200710/116850.html
http://lxhzju.blog.163.com/blog/static/45008200682773039623/

来源