server shut down问题追踪
2015-05-30 11:32
169 查看
近几天在性能测试[/u]过程中,发现loadrunner[/u] Controller经常报
Server “**” has shut down the connection prematurely
。概率很高,现象很奇怪。网上有很多说法,各有不同,但貌似都不正确,只能靠自己追踪。
根据经验仔细分析,发现可能跟下列因素有关:
(1)loadrunner客户端服务器网卡资源不足;
(2)tcp/ip连接超时时间设置太长,造成无连接可用;
(3)应用服务端有问题。
一、用事实做详细的对比:
分析:从对比结果来看,shut
down的比例跟loadrunner客户端确实有关系,但无论客户端怎样改变,还是该现象出现,而且比例始终超过万分之1。
至此,可以排除loadrunner客户端的原因。
二、转向服务端,在dpm服务器上,发现apache占用很大的资源,而且有报错:
(1)在压力情况下,apache(httpd进程)占用的物理内存,平均每秒增涨4M,非常恐怖;
(2)Apache日志中有三类报错信息:
a、 [Tue Jun 30 18:54:37 2009] [error] [client 192.168.**.**]
unable to init Zlib: deflateInit2 returned -4: URL
/distributor/product/my_product_list.htm
b、 [Tue Jun 30 18:54:38 2009] [notice] child pid 28699 exit
signal Segmentation fault (11)
c、Memory allocation failed.
分析:经过观察,推论出httpd进程占用物理内存狂增,导致服务器没有剩余资源分配给它,造成memory allocation
failed。
三、修改和屏蔽一些apache配置项,例如减少SendBufferSize所占空间、屏蔽CustomLog日志。都无济于事。
问题到底出在哪?
经过坚持不懈的追踪,定位到是apache子进程狂吃内存。
根据经验,判断问题可能出在apche加载某个/某些模块上。于是,使用“拆分问题,隔离分析”的分析方法。先隔离出apache加载的所有模块。再采取注释、重启、验证的方式,逐步缩小隔离范围。最终定位出瓶颈点。
系apache在加载一个Taobao**_module时,每秒消耗4M内存,导致apache占用的物理内存不断增涨,当涨至操作系统能分配给
apache的最大内存时,apache子进程死掉。在老的子进程死亡和新的子进程创建的时间间隔,有请求过来,系统自然没有响应,从
loadrunner那端看,就是server shut down。
真相得以大明。接下来就是对这个模块进行优化了。
一个 1.84/千
,背后竟然隐含如此巨大的性能问题。如果不深究,问题很快就被忽视了,系统上线之后,不被上帝眷顾的用户很有可能就打不开网页了。整个瓶颈查找的过程,我想可以让我们想到以下几点:
1. 性能测试工程师需要具备敏锐的观察力,再小的概率,只要出错,必定深究;
2. 性能测试工程师需要有清晰的思路,先查什么,后查什么,要设计得很明确;
3. 除了注重jboss和java程序,apache也应当重点关注,特别是出现error的时候;
4. “拆分问题,隔离分析”的方法确实很实用;
5. 尽信书不如无书,遇到具体问题要具体分析。
转http://www.51testing.com/html/03/n-143203.html
Server “**” has shut down the connection prematurely
。概率很高,现象很奇怪。网上有很多说法,各有不同,但貌似都不正确,只能靠自己追踪。
根据经验仔细分析,发现可能跟下列因素有关:
(1)loadrunner客户端服务器网卡资源不足;
(2)tcp/ip连接超时时间设置太长,造成无连接可用;
(3)应用服务端有问题。
一、用事实做详细的对比:
分析:从对比结果来看,shut
down的比例跟loadrunner客户端确实有关系,但无论客户端怎样改变,还是该现象出现,而且比例始终超过万分之1。
LoadRunner服务器数量 | TcpTimedWaitDelay键值 | 并发用户数 | 平均TPS | shut down比例 |
1台 | 30s | 13 | 76.195 | 万分之18.4 |
1台 | 10s | 7 | 66.49 | 万分之10.8 |
2台 | 10s | 7 | 85.994 | 万分之1.39 |
2台 | 10s | 2 | 33.544 | 万分之1.23 |
二、转向服务端,在dpm服务器上,发现apache占用很大的资源,而且有报错:
(1)在压力情况下,apache(httpd进程)占用的物理内存,平均每秒增涨4M,非常恐怖;
(2)Apache日志中有三类报错信息:
a、 [Tue Jun 30 18:54:37 2009] [error] [client 192.168.**.**]
unable to init Zlib: deflateInit2 returned -4: URL
/distributor/product/my_product_list.htm
b、 [Tue Jun 30 18:54:38 2009] [notice] child pid 28699 exit
signal Segmentation fault (11)
c、Memory allocation failed.
分析:经过观察,推论出httpd进程占用物理内存狂增,导致服务器没有剩余资源分配给它,造成memory allocation
failed。
三、修改和屏蔽一些apache配置项,例如减少SendBufferSize所占空间、屏蔽CustomLog日志。都无济于事。
问题到底出在哪?
经过坚持不懈的追踪,定位到是apache子进程狂吃内存。
根据经验,判断问题可能出在apche加载某个/某些模块上。于是,使用“拆分问题,隔离分析”的分析方法。先隔离出apache加载的所有模块。再采取注释、重启、验证的方式,逐步缩小隔离范围。最终定位出瓶颈点。
系apache在加载一个Taobao**_module时,每秒消耗4M内存,导致apache占用的物理内存不断增涨,当涨至操作系统能分配给
apache的最大内存时,apache子进程死掉。在老的子进程死亡和新的子进程创建的时间间隔,有请求过来,系统自然没有响应,从
loadrunner那端看,就是server shut down。
真相得以大明。接下来就是对这个模块进行优化了。
一个 1.84/千
,背后竟然隐含如此巨大的性能问题。如果不深究,问题很快就被忽视了,系统上线之后,不被上帝眷顾的用户很有可能就打不开网页了。整个瓶颈查找的过程,我想可以让我们想到以下几点:
1. 性能测试工程师需要具备敏锐的观察力,再小的概率,只要出错,必定深究;
2. 性能测试工程师需要有清晰的思路,先查什么,后查什么,要设计得很明确;
3. 除了注重jboss和java程序,apache也应当重点关注,特别是出现error的时候;
4. “拆分问题,隔离分析”的方法确实很实用;
5. 尽信书不如无书,遇到具体问题要具体分析。
转http://www.51testing.com/html/03/n-143203.html
相关文章推荐
- Linux top 命令详解
- MySQL相关查询和操作
- loadrunner常用的函数
- linux下zabbix客户端agentd升级
- linux防火墙相关操作
- 测试如何更有效说服研发去修改bug…
- Linux 查看CPU和内存等信息
- centos6.3下安装loadrunner 1…
- 常去的测试论坛和测试博客
- 测试工具下载
- 安全测试系列二:缓冲区溢出…
- 安全测试系列一:用实例来解…
- zoj 3620 Escape Time II dfs
- 不大开脑洞,怎么谈创造力?
- setInterval 启用和停止,见代码
- 【牛腩新闻发布系统】——母版页图片路径问题
- easyloader
- 两分钟彻底让你明白Android Activity生命周期(图文)!
- 我的测试发展路程
- ORACLE优化方案