51Testing软件测试论坛

标题: 救命呀，系统瓶颈到底在哪里？ [打印本页]

作者: wuliangye 时间: 2012-5-7 10:43
标题: 救命呀，系统瓶颈到底在哪里？
本帖最后由 wuliangye 于 2012-5-7 10:45 编辑

测试的性能分析图如下：[attach]78845[/attach]

[attach]78846[/attach]

[attach]78847[/attach]

[attach]78848[/attach]

[attach]78849[/attach]

[attach]78850[/attach]

[attach]78851[/attach]

[attach]78852[/attach]
从结果看，到20个并发用户时，系统的点击数，吞吐量以及UNIX的资源利用开始下降，但是怎么判断这个瓶颈到底在哪里？各位大侠，请帮忙！！

作者: jj_ljw 时间: 2012-5-7 11:02
你的响应时间不大啊，最高才0.032s。网络吞吐是100M？

作者: wuliangye 时间: 2012-5-7 11:04
是呀，响应时间很小，网络吞吐只有6～7M啊

作者: edisonzhang 时间: 2012-5-7 11:14
你先查看是什么占用这么高的CPU
vmstat top 看下

作者: wuliangye 时间: 2012-5-7 11:23
CPU我看了下，随着并发数增加而增加，等到了20个左右的并发数后，就发现CPU由77%左右开始下降。
我想如果CPU是瓶颈的话，那么并发数增加后CPU应该一直居高不下，应该不会表现出下降的趋势吧？

作者: jj_ljw 时间: 2012-5-7 11:48
测试软件的配置调高点，看看cpu能增大不

作者: wuliangye 时间: 2012-5-7 12:13
TO edisonzhang, jj_ljw:你们都怀疑CPU是瓶颈是么？调高不行的，服务器不在我这边，vmstat top 我不会用，unix系统没用过主要，我要查下资料才行。
TO edisonzhang：有没有其他的怀疑点？

作者: 云层 时间: 2012-5-7 12:32
看起来不是蛮正常的么

作者: wuliangye 时间: 2012-5-7 13:14
云大侠，到20个并发用户时，系统的点击数，吞吐量以及UNIX的资源利用开始下降，我认为20个并发数已经是系统的极限了，那么如何从这个结果中判断出系统瓶颈在哪里。
之前做50个并发时的结果如下：
[attach]78865[/attach]
[attach]78866[/attach]

[attach]78868[/attach]

[attach]78869[/attach]

[attach]78867[/attach]

作者: shotting 时间: 2012-5-7 13:48
20并发用户后点击数、thoughtput随着用户增长并没有增加而是持平和略降，证明20并发后系统出现了拒绝连接的情况。

作者: wuliangye 时间: 2012-5-7 14:19
1. 系统没有限定多少个连接数，UNIX系统的连接数应该不会只有20个吧？
2. 如果是系统拒绝连接，怎么找出原因？

作者: wuliangye 时间: 2012-5-7 14:31
还想问下，如果系统拒绝连接的话，LR客户端应该会有相应的错误日志提示吧？

作者: 云层 时间: 2012-5-7 14:35

云大侠，到20个并发用户时，系统的点击数，吞吐量以及UNIX的资源利用开始下降，我认为20个并发数已经是系统 ...
wuliangye 发表于 2012-5-7 13:14

你时间做长点，我个人觉得可能有资源泄漏。。。。如果一直这样下去最后处理能力消失，那么要么就是排队排死了，要么就是资源漏完了，你先看有啥资源占的多了，具体问题，这里是说不清楚的

作者: wuliangye 时间: 2012-5-7 14:47
我做了一个长的试验，每隔1个小时增加一个用户，到了5个并发数后就不行了：
[attach]78872[/attach]

[attach]78873[/attach]

[attach]78875[/attach]

[attach]78876[/attach]

[attach]78874[/attach]

错误有很多种，有一种是：

[attach]78877[/attach]

作者: jj_ljw 时间: 2012-5-7 15:56
那结论是资源泄露了？

作者: wuliangye 时间: 2012-5-7 16:16
不知道啊,我一直以为是LR客户端内存不够报错，不知道是不是UNIX服务器内存泄漏导致的，高人指点下哈。。。

作者: wuliangye 时间: 2012-5-7 16:18
还有一种错误是：[attach]78893[/attach]

难道不是说LR客户端的内存不够？

作者: 云层 时间: 2012-5-7 16:32
感觉是你脚本编写的问题么？有内存泄漏感觉

作者: wuliangye 时间: 2012-5-7 16:38
云大侠，你是说UNXI服务器有内存泄漏可能，还是LR那台客户端？
关键是我跑的时间短（<3小时），30个用户都不会报错；但是跑了4个小时左右，5个用户都会报错
脚本很简单：
Action()
{
int HttpRetCode;

web_url("auth.jsp",
"URL=http://XX.XX.XX.X/index.jsp",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTML",
LAST);

   HttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE);

   if (HttpRetCode == 200)
{
      lr_start_transaction("Test");
   web_submit_form("index.jsp_2", ITEMDATA,
   "Name=contentId", "Value={content_code}", ENDITEM,
   "Name=userId", "Value={user_code}", ENDITEM,
   "Name=submit", "Value=submit", ENDITEM,
   LAST);
      lr_end_transaction("epimonth", LR_AUTO);
   return 0;
   }
   else
   {
   lr_start_transaction("error-html");
   lr_log_message("ok");
   lr_end_transaction("error-html", LR_AUTO);
   return 0;
   }
   return 0;
}

作者: jj_ljw 时间: 2012-5-7 17:28
测试系统登录操作，不太复杂吧，是不是不加判断直接运行登录事务会好点。
另外测试机的资源消耗不大吧

作者: 云层 时间: 2012-5-7 17:38
干嘛要自己判断200状态呢？LR都会自己判断的，而且这种判断没有意义，走检查点判断

作者: wuliangye 时间: 2012-5-8 09:30
好的，我把判断去掉，再运行下。。。
昨晚跑了一下，还是报那两个错误，26000：Not enough Memeory

作者: wuliangye 时间: 2012-5-8 11:19
Error still:[attach]78901[/attach]

作者: 云层 时间: 2012-5-8 11:21
你自己电脑是不是真的最后内存不够了？

作者: edisonzhang 时间: 2012-5-8 12:01
回复 4# edisonzhang

不对，当20并发时，系统的处理能力降低，cpu有可能下降

作者: wuliangye 时间: 2012-5-8 12:29
刚看了下，当时的LR客户机上内存和虚存都在2G左右，而LR客户机内存大小8G，虚存我也调整到远远大于2G，
怎么会老是出现内存不够的错误呢？

作者: 鹭岛 时间: 2012-5-8 12:36
你这个是什么程序？JAVA的么?还是，最好看下类的情况，感觉是内存泄漏

作者: wuliangye 时间: 2012-5-8 13:01
恩，是的，JAVA的程序

作者: wuliangye 时间: 2012-5-8 13:10
LR所在的进程内存和虚存使用情况：
[attach]78902[/attach]

虚拟地址空间：

[attach]78903[/attach]

内存和虚存到了2G,虚拟地址空间到了2G

作者: wuliangye 时间: 2012-5-8 13:15
难道是脚本本身有内存泄漏？导致运行时间稍微长一点就会报错？

，到底是神马情况呀。。。

作者: anna03 时间: 2012-5-8 17:07
看一下jvm内部的内存情况，用jconsole

作者: yuanyuan_wo 时间: 2012-5-9 20:16
怎么看得出来这个吞吐量是6-7m的啊,35分钟的时候是,350000bytes,那350000/1024=85,我这样算对不对呢??

作者: 菜鸟@大虾 时间: 2012-5-10 18:00
just try it

作者: bob123654 时间: 2012-5-11 08:53
貌似真的有内存泄露，看你的截图1个小时增加1个用户，那个Running Vusers图是不是有问题啊？看着好奇怪

作者: hongchongren 时间: 2012-5-14 15:15
你的服务器是多少个CPU的？

作者: liulang 时间: 2012-5-14 17:40
就用1个用户跑长时间呢

作者: 晴空白鹤 时间: 2012-5-14 19:21
回复 19# wuliangye

脚本是不是有错啊，第一个事务的开始事务名称和结束事务的名称不一致啊。
另外是从上面的图片看不出内存泄露啊，云大师是怎么看的，能不能指导一下啊？
看图片可能是网络瓶颈吧，期待大师们指导。

作者: 晴空白鹤 时间: 2012-5-14 19:26
回复 32# yuanyuan_wo

这样子计算肯定是不对的。
但到底怎么算，请大师们指导吧，我也是菜鸟。期待回复。

作者: wuliangye 时间: 2012-5-15 09:41
TO hongchongren:CPU是8核的
To liulang：我还没试过1个用户长时间跑，可以试下
To bob123654：一个小时增加一个用户

作者: 零测试 时间: 2012-5-15 21:49
一个进程只有一个用户还是一个进程里包含多个用户（一个进程里多个线程，每个线程是一个虚拟用户）

作者: sunnyswu 时间: 2012-5-15 22:20
呵呵这个，大概不是内存泄露吧，可以看看在3小时，到4小时之久内存的变化，
或许是代码的原因的，比如jdbc连接未释放，都是原因。

作者: sunnyswu 时间: 2012-5-15 22:23
CPU，内存不够都是现象，现在目的是找到什么原因引起这些现象，
脚本应该也没有问题。
可以看这个功能都有什么操作，比如是否连接数据库，是否有其他的操作，从程序的流程去考虑，找到其中的问题，一般来讲配置方面的问题也会有，比较少。

作者: wuliangye 时间: 2012-5-16 16:15
To 零测试:以线程方式运行，一个进程包含多个用户

作者: wuliangye 时间: 2012-5-18 16:57
今天问了一下几位测试前辈，初步怀疑点和大家分享如下：
1. 到了20个并发用户后，事务数没有随着用户数增加而增加，有可能是中间件做了用户数的限制；
2. 到了20个并发用户后，UNIX的CPU没有随着用户数增加而增加，有可能CPU是瓶颈；

作者: xxllff2000 时间: 2012-5-18 18:00
楼主TPS=1000+？？我TPS做下来只有80啊

作者: jj_ljw 时间: 2012-5-19 11:08
开始没注意到tps得图，ls说得对，tps高了，1000+，就是每小时访问3600000次

作者: 夏美932926954 时间: 2012-5-19 20:50
学习中。。。

作者: femir 时间: 2012-5-20 21:00
很明显服务器有内存泄漏，时间长memory就不够用了，down了，
lr_start_transaction("Test");
........
lr_end_transaction("epimonth", LR_AUTO);
你这个事务结束判断点是什么意思，要是上一个Test的事务的话就不对啊
为了确认是不是你写的代码的问题，你录制一份脚本跑一把，看看结果比较哈就晓得了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)