别让她蒙上你的眼——进程干扰导致的性能测试失败

qaarchitech · 发表于 2008-6-10 13:08:55

by jack
先给大家看几个由LoadRunner的场景运行产生的结果报表（Analysis输出结果）
首先是Average Transaction Response Time图

然后是Unix Resources图

Unix Resources数据表格

这是前一段时间某个同学性能测试的报告中的图。当时看到这个图我马上问了一下：
问：这个是什么类型的应用？
答：纯java，ip：10.0.65.105是应用服务器
问：为什么中间有那么大的响应时间的陡升？
答：测了好几次都有的
问：找到原因了吗？
答：没有
问：Unix Resources里面的应用服务器的swap是怎么回事？
答：不知道……没注意
其实这个同学性能测试报告总结部分写得不错，但仔细看了一下图表，发现了些问题，就马上提出给他了。
这次性能测试的结果是不可靠的。为什么呢？
要说清这个问题，还需要先简单提一下jvm调优：纯java应用（没有在java进程外的应用程序），其内存使用变化在jvm内；通常我们调优jvm都会注意的就是在满足应用运行所需要的内存前提下，还要让jvm最大内存小于剩余物理内存，这样避免了使用虚拟内存造成的磁盘io。
从上面这段介绍可以看出，纯java应用，正常调优后，其服务器表现出来的Unix Resources中的swap应该一直为0
那么swap是怎么出现的呢？很简单，物理内存不足。为什么会物理内存不足呢？对于本文提到的这次性能测试来说，不外两种可能：
1.jvm内存最大值过大，超过剩余物理内存
2.其它进程占用内存导致物理内存不足
与做这次性能测试的同学核对过后证实：是第二种原因，而响应时间的陡升，也是该时刻大量磁盘io导致io wait引起的响应变慢。
在我们做性能测试的过程中，一定要保证环境的纯净，特别是不能受到一些内存用量大、cpu占用率高的进程的干扰；最好能在运行场景前重启服务器。
另外在linux系统的性能测试中，常常把着眼点总放在cpu，load上，有时会忽略内存的影响，这也告诉了我们：对待性能测试必须谨慎；对报告数据的自信来自于认真和细致的工作。
附件: