nginx遇到个错误
jdzc...@hotmail.com
nginx日志显示
2009/05/23 00:07:32 [error] 4464#0: *33638 upstream prematurely closed
connection while reading response header from upstream, client:
192.168.1.11, ×××××
nginx配置参数主要是
#user nobody;
worker_processes 8;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
use epoll;
worker_connections 8012;
}
server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
client_max_body_size 8m;
sendfile on;
tcp_nopush on;
keepalive_timeout 10;
tcp_nodelay on;
fastcgi_connect_timeout 120;
fastcgi_send_timeout 120;
fastcgi_read_timeout 120;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css
application/xml;
gzip_vary on;
Yorgo Sun
从日志上来看是你的后端返回时出了问题，但是你的配置文件里没有描述这部分，所以，不太清楚具体的问题了
--
孙绍轩 Yorgo Sun
坏人
Yorgo Sun
--
孙绍轩 Yorgo Sun
坏人
On 5月25日, 上午7时05分, Yorgo Sun <yorgo...@gmail.com> wrote:
> 看你是哪个Fcgi的实际服务了，php这种要差一点，因为它是进程模式，一个并发连接就要启动一个进程来服务，所以并发越多，越要有足够的服务进程，但一个进-程大概消耗4-5M内存，其实一台机器也启动不了多少，所以也扛不了多少流量，并发小就没有问题。
Yorgo Sun
--
孙绍轩 Yorgo Sun
Delta Yeh
Yorgo Sun
机器是有2G内存的，出问题的时候是开着8个nginx worker process，当时显示平均每个占用4%的内存，同时开启了100左右的php fcgi，一个大概是4～5M内存吧，系统忽然的就内存吃空开始消耗swap，十分奇怪。
曾经在4G的机器上也出现过这样的问题，一开始以为php有问题，但是现在开始怀疑nginx也连带有问题了，因为最终是要将nginx重启后才释放了那些占用的内存。而且kill -HUP pid时shutdown的worker很慢，需要等很长时间才停下来。
不知道你有没有遇到过这样的情况，我现在更新到最新版本就是想看看能否解决这个问题。目前出问题的时候使用的版本是0.6.xx的那个稳定版本
--
孙绍轩 Yorgo Sun
Delta Yeh
特别是TCP相关的内存参数。
如果有很多空置的连接，也可能耗尽系统内存。
sysctl -a |grep "tcp"看看 ？
Yorgo Sun
--
孙绍轩 Yorgo Sun
Delta Yeh
根据
net.ipv4.tcp_rmem = 4096 87380 4194304
我曾经碰到过因为TCP的内存设置的过大，空闲的网络连接和孤儿SOCKET消耗了50%系统内存的情况。
Yorgo Sun
坏人
> 2009/5/26 Delta Yeh <delta....@gmail.com>
>
>
>
>
>
> > 你的协议栈参数是怎么设置的？
> > 特别是TCP相关的内存参数。
> > 如果有很多空置的连接，也可能耗尽系统内存。
> > sysctl -a |grep "tcp"看看 ？
>
> > 2009/5/26 Yorgo Sun <yorgo...@gmail.com>
>
> >> 是的，所以怀疑不知道那里产生的内存泄露
>
> >> 机器是有2G内存的，出问题的时候是开着8个nginx worker process，当时显示平均每个占用4%的内存，同时开启了100左右的php
> >> fcgi，一个大概是4～5M内存吧，系统忽然的就内存吃空开始消耗swap，十分奇怪。
>
> >> 曾经在4G的机器上也出现过这样的问题，一开始以为php有问题，但是现在开始怀疑nginx也连带有问题了，因为最终是要将nginx重启后才释放了那些占用-的内存。而且kill
> >> -HUP pid时shutdown的worker很慢，需要等很长时间才停下来。
>
> >> 不知道你有没有遇到过这样的情况，我现在更新到最新版本就是想看看能否解决这个问题。目前出问题的时候使用的版本是0.6.xx的那个稳定版本
>
> >> 2009/5/26 Delta Yeh <delta....@gmail.com>
>
> >> nginx一般只占用很少内存的。
>
> >>> 2009/5/26 Yorgo Sun <yorgo...@gmail.com>
>
> >>> 今天早上就遇到了，内存吃干，开始使用swap区了，重启后恢复了，不知道是因为php fcgi的问题还是nginx的问题
>
> >>>> 2009/5/26 坏人 <eel...@foxmail.com>
>
> >>>> 我碰到过因fcgi承受不了压力而导致nginx也出错的情况
>
> >>>>> On 5月25日, 上午7时05分, Yorgo Sun <yorgo...@gmail.com> wrote:
>
> >>>>> 看你是哪个Fcgi的实际服务了，php这种要差一点，因为它是进程模式，一个并发连接就要启动一个进程来服务，所以并发越多，越要有足够的服务进程，但一个进--程大概消耗4-5M内存，其实一台机器也启动不了多少，所以也扛不了多少流量，并发小就没有问题。
> >>>>> > 其它语言类似Python的我觉得可能好点吧，毕竟它内部是线程模式的，但是我没有实际测试过。从原理上感觉应该好点
>
> >>>>> > 2009/5/24 坏人 <eel...@foxmail.com>
>
> >>>>> > > fcgi能承受压力不？
>
> >>>>> > --
> >>>>> > 孙绍轩 Yorgo Sun
>
> >>>> --
> >>>> 孙绍轩 Yorgo Sun
>
> >> --
> >> 孙绍轩 Yorgo Sun
>
> --
> 孙绍轩 Yorgo Sun- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Yorgo Sun
坏人
> > 曾经在4G的机器上也出现过这样的问题，一开始以为php有问题，但是现在开始怀疑nginx也连带有问题了，因为最终是要将nginx重启后才释放了那些占用--的内存。而且kill
> > > >> -HUP pid时shutdown的worker很慢，需要等很长时间才停下来。
>
> > > >> 不知道你有没有遇到过这样的情况，我现在更新到最新版本就是想看看能否解决这个问题。目前出问题的时候使用的版本是0.6.xx的那个稳定版本
>
> > > >> 2009/5/26 Delta Yeh <delta....@gmail.com>
>
> > > >> nginx一般只占用很少内存的。
>
> > > >>> 2009/5/26 Yorgo Sun <yorgo...@gmail.com>
>
> > > >>> 今天早上就遇到了，内存吃干，开始使用swap区了，重启后恢复了，不知道是因为php fcgi的问题还是nginx的问题
>
> > > >>>> 2009/5/26 坏人 <eel...@foxmail.com>
>
> > > >>>> 我碰到过因fcgi承受不了压力而导致nginx也出错的情况
>
> > > >>>>> On 5月25日, 上午7时05分, Yorgo Sun <yorgo...@gmail.com> wrote:
>
> > 看你是哪个Fcgi的实际服务了，php这种要差一点，因为它是进程模式，一个并发连接就要启动一个进程来服务，所以并发越多，越要有足够的服务进程，但一个进---程大概消耗4-5M内存，其实一台机器也启动不了多少，所以也扛不了多少流量，并发小就没有问题。
Yorgo Sun
坏人
你有什么特殊要求？很久没碰到设置60秒的高人了，膜拜一下
这么说吧，一般情况下alive设置的时间长，节省了新发tcp连接的消耗，但是服务期内浪费的资源却多得多，得不偿失。这个我做过压力测试
> > 曾经在4G的机器上也出现过这样的问题，一开始以为php有问题，但是现在开始怀疑nginx也连带有问题了，因为最终是要将nginx重启后才释放了那些占用---的内存。而且kill
> > > > > >> -HUP pid时shutdown的worker很慢，需要等很长时间才停下来。
>
> > 不知道你有没有遇到过这样的情况，我现在更新到最新版本就是想看看能否解决这个问题。目前出问题的时候使用的版本是0.6.xx的那个稳定版本
>
> > > > > >> 2009/5/26 Delta Yeh <delta....@gmail.com>
>
> > > > > >> nginx一般只占用很少内存的。
>
> > > > > >>> 2009/5/26 Yorgo Sun <yorgo...@gmail.com>
>
> > > > > >>> 今天早上就遇到了，内存吃干，开始使用swap区了，重启后恢复了，不知道是因为php fcgi的问题还是nginx的问题
>
> > > > > >>>> 2009/5/26 坏人 <eel...@foxmail.com>
>
> > > > > >>>> 我碰到过因fcgi承受不了压力而导致nginx也出错的情况
>
> > > > > >>>>> On 5月25日, 上午7时05分, Yorgo Sun <yorgo...@gmail.com> wrote:
>
> > 看你是哪个Fcgi的实际服务了，php这种要差一点，因为它是进程模式，一个并发连接就要启动一个进程来服务，所以并发越多，越要有足够的服务进程，但一个进----程大概消耗4-5M内存，其实一台机器也启动不了多少，所以也扛不了多少流量，并发小就没有问题。
Yorgo Sun
--
孙绍轩 Yorgo Sun
坏人
On 6月1日, 上午9时29分, Yorgo Sun <yorgo...@gmail.com> wrote:
> 我后台有fcgi，也有一个proxy到一个长连接服务上，那个长连接是一个准长连接，大概30秒会断一次，但是，keepalive会使得物理连接没有断，只-是客户端重新再逻辑连接一次而已。
> > 曾经在4G的机器上也出现过这样的问题，一开始以为php有问题，但是现在开始怀疑nginx也连带有问题了，因为最终是要将nginx重启后才释放了那些占用----的内存。而且kill
> > > > > > > >> -HUP pid时shutdown的worker很慢，需要等很长时间才停下来。
>
> > > > 不知道你有没有遇到过这样的情况，我现在更新到最新版本就是想看看能否解决这个问题。目前出问题的时候使用的版本是0.6.xx的那个稳定版本
>
> > > > > > > >> 2009/5/26 Delta Yeh <delta....@gmail.com>
>
> > > > > > > >> nginx一般只占用很少内存的。
>
> > > > > > > >>> 2009/5/26 Yorgo Sun <yorgo...@gmail.com>
>
> > > > > > > >>> 今天早上就遇到了，内存吃干，开始使用swap区了，重启后恢复了，不知道是因为php fcgi的问题还是nginx的问题
>
> > > > > > > >>>> 2009/5/26 坏人 <eel...@foxmail.com>
>
> > > > > > > >>>> 我碰到过因fcgi承受不了压力而导致nginx也出错的情况
>
> > > > > > > >>>>> On 5月25日, 上午7时05分, Yorgo Sun <yorgo...@gmail.com> wrote:
>
> > 看你是哪个Fcgi的实际服务了，php这种要差一点，因为它是进程模式，一个并发连接就要启动一个进程来服务，所以并发越多，越要有足够的服务进程，但一个进-----程大概消耗4-5M内存，其实一台机器也启动不了多少，所以也扛不了多少流量，并发小就没有问题。
Delta Yeh
因为是程序自动发起连接，连接发起还是很快的。
一个首页用10秒来显示，应该也能传比较多内容的了，
所以10秒钟应该能满足大部分的站点了。
坏人
而如果是动态网站的动态内容部分，或是超大的静态文件，设置越小越好（比如论坛、下载站）
如果是正常请求10秒是没问题，你考虑过非正常连接没？据我的网站实际运行监控来看，有相当数量的非正常连接，这种都是过度消耗资源的罪魁祸首
On 6月1日, 下午10时33分, Delta Yeh <delta....@gmail.com> wrote:
> 0秒就是关掉keepAlive了。
> 因为是程序自动发起连接，连接发起还是很快的。
> 一个首页用10秒来显示，应该也能传比较多内容的了，
> 所以10秒钟应该能满足大部分的站点了。
>
> 2009/6/1 坏人 <eel...@foxmail.com>
>
>
>
> > 5秒内可以，一般应用就是0秒，5秒，大负载下超过10秒的都不多见
>
> > On 6月1日, 上午9时29分, Yorgo Sun <yorgo...@gmail.com> wrote:
>
> > 我后台有fcgi，也有一个proxy到一个长连接服务上，那个长连接是一个准长连接，大概30秒会断一次，但是，keepalive会使得物理连接没有断，只--是客户端重新再逻辑连接一次而已。
> > 曾经在4G的机器上也出现过这样的问题，一开始以为php有问题，但是现在开始怀疑nginx也连带有问题了，因为最终是要将nginx重启后才释放了那些占用-----的内存。而且kill
> > > > > > > > > >> -HUP pid时shutdown的worker很慢，需要等很长时间才停下来。
>
> > > > > > 不知道你有没有遇到过这样的情况，我现在更新到最新版本就是想看看能否解决这个问题。目前出问题的时候使用的版本是0.6.xx的那个稳定版本
>
> > > > > > > > > >> 2009/5/26 Delta Yeh <delta....@gmail.com>
>
> > > > > > > > > >> nginx一般只占用很少内存的。
>
> > > > > > > > > >>> 2009/5/26 Yorgo Sun <yorgo...@gmail.com>
>
> > > > > > > > > >>> 今天早上就遇到了，内存吃干，开始使用swap区了，重启后恢复了，不知道是因为php
> > fcgi的问题还是nginx的问题
>
> > > > > > > > > >>>> 2009/5/26 坏人 <eel...@foxmail.com>
>
> > > > > > > > > >>>> 我碰到过因fcgi承受不了压力而导致nginx也出错的情况
>
> > > > > > > > > >>>>> On 5月25日, 上午7时05分, Yorgo Sun <yorgo...@gmail.com>
> > wrote:
>
> > 看你是哪个Fcgi的实际服务了，php这种要差一点，因为它是进程模式，一个并发连接就要启动一个进程来服务，所以并发越多，越要有足够的服务进程，但一个进------程大概消耗4-5M内存，其实一台机器也启动不了多少，所以也扛不了多少流量，并发小就没有问题。
>
> > 其它语言类似Python的我觉得可能好点吧，毕竟它内部是线程模式的，但是我没有实际测试过。从原理上感觉应该好点
>
> > > > > > > > > >>>>> > 2009/5/24 坏人 <eel...@foxmail.com>
>
> > > > > > > > > >>>>> > > fcgi能承受压力不？
>
> > > > > > > > > >>>>> > --
> > > > > > > > > >>>>> > 孙绍轩 Yorgo Sun
>
> > > > > > > > > >>>> --
> > > > > > > > > >>>> 孙绍轩 Yorgo Sun
>
> > > > > > > > > >> --
> > > > > > > > > >> 孙绍轩 Yorgo Sun
>
> > > > > > > > > --
> > > > > > > > > 孙绍轩 Yorgo Sun- 隐藏被引用文字 -
>
> > > > > > > > > - 显示引用的文字 -
>
> > > > > > > --
> > > > > > > 孙绍轩 Yorgo Sun- 隐藏被引用文字 -
>
> > > > > > > - 显示引用的文字 -
>
> > > > > --
> > > > > 孙绍轩 Yorgo Sun- 隐藏被引用文字 -
>
> > > > > - 显示引用的文字 -
>
> > > --
> > > 孙绍轩 Yorgo Sun- 隐藏被引用文字 -
>
> > > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Weibin Yao
模块首先判断来源请求是否合法，如果合法，就根据请求的ID将请求转发给相应的
后端服务器，否则返回404。
前天开始在线上测试，发现有内存泄露的问题，基本每天泄露13Mb左右，平均每秒
泄露150个字节，并发连接有上千，负载较重。
我的配置是这样的：
“
location /photo/ {
dfs proxy_only;
dfs_remote_fetch proxy;
dfs_proxy_dir /dfs_proxy/;
...
#该模块将合法的请求转发到/dfs_proxy/下面，转发时的uri类似：/dfs_proxy/内
网IP/正常URI。
}
location /dfs_proxy/ {
internal;
if ($uri ~* ^/dfs_proxy/(.*)$) {
set $proxy_uri $1;
proxy_pass $scheme://$proxy_uri;
break；
}
return 404；
}
”
我的模块处理流程是这样的：
1、配置结构体内存：在cf->pool上，分配一个module_loc_conf结构体。
2、请求上下文结构体内存：在r->pool上，分配一个module_ctx结构体。
3、请求的处理过程：
（1）请求过来，先解析uri，获取md5和id。根据id算出md5值，如果与uri上的md5
值不一样，返回404。
（2）根据（1）中的id及服务器上某个文件获取id与后端服务器的对应关系，找出
真实的后端服务器。
（3）通过ngx_http_internal_redirect转发到/dfs_proxy代理目录。
以上过程中，涉及到的动态内存分配，均在r->pool上进行。
今天仔细看了一天的代码了，也没查出到底是哪里出了问题，也苦于没有什么好的
方法可以找到内存泄露的位置，希望各位兄弟帮忙分析分析，讲下可能出问题的地
方。谢谢了。
Delta Yeh
姚伟斌
基本上就是三个函数：
MD5_Init()
MD5_Update()
MD5_final()
MD5的context是静态分配的。
代码明天再贴上来，谢谢了。
坏人
流量大的时候你就会发现cpu在傻傻的一直计算md5，然后结果没啥用，很搞笑的事情。虽然现在cpu很强，但不代表并发处理很强
等你的代码，你现在发的这些看不出
坏人
小网站还没啥，大网站应该避免任何资源的浪费。cpu资源只有30%时并不代表这时的处理能力是空载的30%，可能连1%都不到
On 6月2日, 下午7时46分, Delta Yeh <delta....@gmail.com> wrote:
> 我倒，没有代码，咋分析？
> 远程盲诊？
> 每秒150个字节，不会是MD5的值泄漏？
>
> 2009/6/2 Weibin Yao <nbubi...@gmail.com>
> > 方。谢谢了。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Weibin Yao
> 我建议开发一个nginx用的url hash模块，用md5或是sha1感觉是杀鸡用牛刀，不用那么复杂，部分条件下唯一就行了
> 小网站还没啥，大网站应该避免任何资源的浪费。cpu资源只有30%时并不代表这时的处理能力是空载的30%，可能连1%都不到
>
不过这里的功能不是我能决定的啊，这是以前遗留下来的，原先用的是apache的模
块，现在改用在nginx上面。
--
Weibin Yao
Weibin Yao
> 小网站还没啥，大网站应该避免任何资源的浪费。cpu资源只有30%时并不代表这时的处理能力是空载的30%，可能连1%都不到
>
>
--
Weibin Yao