2.3 共性问题
2.31 虚拟客户脚本 Run-time Setting 中的线程和进程运行方式的区别?
如果选择 Run Vuser as a process, 则场景运行时会为每一个虚拟用户创建一个进程; 选择 Run Vuser as a thread 则将每个虚拟用户作为一个线程来运行, 在任务管理器中只看到一个 mmdrv.exe, 这种方式的运行效率更高, 能造成更大的压力, 时默认选 项
另外, 如果启用了 IP 欺骗功能, 则先在 Controller 中选中 Tools 菜单下的 Expert Mode, 然后将 Tools 菜单下的 Options>General 标签页中的 IP 地址分配方式也设置为与 Vuser 运行方式一致, 同为线程或进程方式
2.32 thinktime 与 pacing 的设置对脚本及场景的影响
在我测试的过程中在稳定性测试场景中有一次我对场景中的一个脚本取消了 pacing 设置, 结果导致 VU 退出, 出现了内存冲突的错误
在我们测试中 BancsLink_C63601_C63603_短信功能定制和删除 BancsLink_C60422_C60423_活期与定期批次转出关联 BancsLink_C67050_C67000_修改客户信息提示等交易, 不加 thinktime 时也会报错
首先我们要明确设置他们的意义
Pacing 是通过设置两次迭代之间的间隔时间, 来调整各个 action 之间的步调从定义上来看, 它是和 iteration 绑定在一起的 Pacing 的设置可以调节系统压力的大小, 影响系统处理事务的能力在场景运行中 pacing 的设置是很重要的
Think time 是通过设置思考时间, 来模拟真实用户在操作过程中的等待时间从定义上来看, 它是在 iteration 内部的某个 action 中各个步骤的间隔时间, 主要目的在于模拟真实用户操作情况, 在测试中使虚拟用户对业务的操作更接近实际
示例: 假设用户进行一次操作会消耗 5 秒钟的时间, 即完成整个迭代需要 5 秒钟如果用户不停顿, 继续第二次重复操作, 则同样耗费约 5 秒左右的时间但是真实世 界中肯定是有停顿的一个真正的用户, 做完一系列操作后, 会间隔一段时间假定用户停顿了 5 秒, 再第二次重复操作, 则一共耗费 10 秒钟时间映射到 loadrunner 中, 就需要在一次 iteration 中, 设置一个 thinktime = 1 秒, 然后在两个 iteration 之间, 设置一个 pacing 为 5 秒
2.33 在运行场景中两个 vu 并发时交易出现错误, 在脚本中没有出现这种情况
查看日志发现两 vu 所使用的参数值是一样的, 所以在接收报文时 VU 不能对应的找到自己的接收报文
解决办法
1 在场景中修改 VU 家在策略, 有一次全部加载改为逐步加载
2 改变取参策略, 把数据分块, 然后分到固定的 VU
2.34 题描述 Deleted the current transaction ... since response time is not accurate
出现这个问题时 TPS 大幅下降, VU 并没有掉这个问题不多遇见, 在调试稳定性测试场景中遇到几次一般出现在压力机器上发生 ping 值为负数时, 可以重新启动 pc 机或者打补丁, 如果还不行把场景另存.
2.35 日志缓存过小: to Log cache is too small to contain the message.
由于场景中 Auto Log cache 默认设置为 1k, 但是遇到报文较长的交易时自动日志缓存的容量就太小了我们就得手动修改
2.36 运行中掉 VU
1 出现 Action.c(35): Error : save param parameter is invalid. Error code : 9005. Error -- memory violation : Exception ACCESS_VIOLATION received.
内存冲突的问题很普遍, 有些程序设置之间的冲突也会导致这个错误, 就脚本里来讲, HTTP 录制的脚本里面关联错误会导致内存冲突; 在 socket 协议的脚本里判断成功时我们一般采用字母数字与存储在缓冲区里的报文做匹配, 但是我们存在缓冲区里面的报文是二进制格式的, 所以在场景中也会造成内存冲突, 最后掉 VU 可能一个很小的问题就会引起内存冲突
2 内存资源不足: 脚本中的事务执行后没有释放 buffer, 最好在每个事务结束后就释放 buffer
3 压力过大: 压力过大导致本地存储收回报文的存储空间不足, 写不了日志也会掉 VU
4 参数取值不正确也可能导致掉 VU
5 系统自身原因
总体来说, 解决方法就是调整脚本分成多台压力机进行测试
2.37 为什么 Windows 系统中的 CPU 内存等资源仍然充足, 但是模拟的用户数量却上不去?
在 Windows 计算机的标准设置下, 操作系统的默认限制只能使用几百个 Vuser, 这个限制与 CPU 或内存无关, 主要是操作系统本身规定了默认的最大线程数所导致要想突破 Windows 这个限制, 须修改 Windows 注册表以 Windows XP Professional 为例
(1) 打开注册表后, 进入注册表项 HKEY_LOCAL_MACHINE 中的下列关键字: System\CurrentControlSet\Control\Session Manager\SubSystems
(2) 找到 Windows 关键字, Windows 关键字如下所示:
- %SystemRoot%\system32\csrss.exe bjectDirectory=\Windows
- SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1
- ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2
- ProfileControl=Off MaxRequestThreads=16
SharedSection=1024,3072,512 关键字的格式为 xxxx,yyyy,zzz 其中, xxxx 定义了系统范围堆的最大值 (以 KB 为单位),yyyy 定义每个桌面堆得大小
(3) 将 yyyy 的设置从 3072 更改为 8192(即 8MB), 增加 SharedSection 参数值
通过对注册表的更改, 系统将允许运行更多的线程, 因而可以在计算机上运行更多的 Vuser 这意味着能够模拟的最大并发用户数量将不受 Windows 操作系统的限制, 而只受硬件和内部可伸缩性限制的约束
2.38 问题描述 open many files
问题一般都在压力较大的时候出现, 由于服务器或者应用中间件本身对于打开的文件数有最大值限制造成, 解决办法:
1 修改操作系统的文件数限制, aix 下面修改 limits 下的 nofiles 限制条件, 增大或者设置为没有限制, 尽量对涉及到的服务器都作修改
2 方法一解决不了情况下再去查看应用服务器 weblogic 的 commonEnv.sh 文件, 修改其中的 nofiles 文件 max-nofiles 数增大, 应该就可以通过了, 具体就是查找到 nofiles 方法, 修改其中 else 条件的执行体, 把文件打开数调大修改前记住备份此文件, 防止修改出错
3linux 上可以通过 ulimit HSn 4096 来修改文件打开数限制, 也可以通过 ulimit -a 来查看
4linux 上可以通过 lsof -p pid | wc -l 来查看进程打开的句柄数
2.38 LoadRunner 与服务器连接时遇到的问题
(1)ERROR:sck connect Aborted
这种错误一般是软件造成连接中断由于软件错误, 造成一个已经建立的连接被取消, 比如 LoadRunner 自身的 bug, 在发报文时多位典型情况下, 这意味着连接是由于协议或超时错误而被取消的
(2)ERROR:Failed to connect to server
这个问题一般是客户端链接到服务失败, 原因有两个客户端连接限制 (也就是压力负载机器), 一个网络延迟严重, 解决办法:
1 修改负载机器的 tcpdelaytime 注册表键值, 将其改小改小;
2 检查网络延迟情况, 看问题出在什么环节;
为了减少这种情况, 最好测试中有个干净的网络环境, 每个负载机器的压力测试用户数不易过大, 尽量平均每台负载器的用户数, 这样以上问题出现的概率就会减小
(3)ERROR:has shut down the connection prematurely
分为以下三种情况:
1. 应用访问死掉
小用户时: 程序上的问题或数据库的问题 , 应该查看一下 sql 执行效率和 JAV 的垃圾回收情况, 具体定位问题
2. 应用服务没有死
应用服务参数设置问题
例如:
在许多客户端连接 Weblogic 应用服务大部分被拒绝, 而在服务器端没有错误显示, 则有可能是 Weblogic 中的 server 元素的 AcceptBacklog 属性值设得过低如果连接时收到 connection refused 消息, 说明应提高该值, 每次增加 25%Java 连接池的大小设置, 或 JVM 的设置等
3. 数据库的连接
在应用服务的性能参数可能太小了
数据库启动的最大连接数 (跟硬件的内存有关)
(4)ERROR: connection refused.
这种情况比较复杂, 需要检查几个地方, 不同的操作系统也会有不同的操作方式
1.首先检查是不是连接 weblogic 服务大部分被拒绝, 监控 weblogic 的连接等待情况, 可能与上面的一样需要增加 AcceptBacklog, 如果没有解决问题, 还要增加增加连接池, 调整线程数,(连接池数 * Statement Cache Size) 的值应该小于数据库连接数的最大值
2.查看服务器的操作系统中是否对连接数做了限制, AIX 下可以直接编辑 limit 文件, 修改连接数端口数的限制以及 tcp 连接等待时间的间隔大小若是 windows 系统, 则要修改其注册表, 修改 TcpTimeWaitDelay(默认值 30s) 和 MaxUserPort(可以调到小于最大值) 项, 键值在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Tcpip\Parameters \ 因为当负载生成器的性能很好时, 发数据包特别快, 服务器响应也很快, 从而导致负载生成器的端口在没有 timeout 之前就占满了端口没有可用的时候就会出现错误, 执行 netstat-na 命令, 可以查看端口如果调整了 TCP 的 timeout, 情况会好点, 在端口还没有占满前就有释放的了
来源: http://www.bubuko.com/infodetail-2494733.html