zwh-Seeking

  性能测试中,CPU和内存是关注最多的两个性能指标。以我行应用最多的系统架构(WAS+Oracle)来说,CPU使用率高的问题多发生于数据库,比如索引不当引发的表扫描、绑定变量使用不当引发的硬解析、连接池使用不当引发的频繁建立断开连接,这些都会导致数据库服务器CPU使用率高。

  内存问题则多发生于应用服务器。部署在WAS平台的Java应用,经常发生的问题是JVM堆内存溢出。产生该问题的原因有很多:

  ·由环境引发的,虚拟机物理内存不足;

  ·由参数配置引发的,JVM堆内存设置过小;

  ·由应用程序引发的,内存泄露,错误使用大对象等等。

  在实际性能测试过程中选择监控指标时,对JVM堆内存的监控分析比对操作系统内存的分析更为重要。JVM堆内存溢出的原因中,虚拟机物理内存不足常常被忽视。本文结合项目测试过程中发现的由内存不足引发的性能问题,设计几个场景来探索JVM堆内存和虚拟机内存之间的影响关系。


一、

莫名其妙的“会话超时”

  在某交易(登录+查询+退出)的疲劳场景中,发现应用服务器内存使用率超过90%,且被测交易存在大量报错:用户未登录或已超时,请登录。WAS中会话相关的两个参数,最大内存中会话数1000和会话超时30分钟。性能测试场景中,会话数使用不到1000,且登录之后并没有退出,也不会发生用户未登录或已超时。所以,报错的原因在哪里?

  WAS的JVM堆内存和操作系统内存状态如图所示。

 

  可以看到,JVM堆内存的分配达到最大值3G,堆实际使用值在到达3G时发生GC,循环如是。JVM堆内存未发生内存溢出,没有生成heapdump、javacore文件,Server没有重启。操作系统内存使用已达92%,且Swap空间使用了1G左右。

  Swap分区通常被称为交换分区,这是一块特殊的磁盘空间,当实际内存不够用的时候,操作系统会从内存中取出一部分暂时不用的数据,放在交换分区中,从而为当前运行的程序腾出足够的内存空间。也就是说,当操作系统开始使用Swap空间时,就意味着内存不够。同时,由于Swap分区是磁盘空间,使用Swap分区会频繁读写磁盘,这会显著降低操作系统的运行速度。

  根据以上分析,初步判断,虚拟机内存不足,使用到Swap分区。如果session信息被从内存交换到Swap分区,那这段时间该线程的查询请求,无法验证到session,就会报“用户未登录或已超时,请登录”,交易失败;如果session信息又被从Swap交换至内存,又不报错,交易成功。下面通过一些实验来验证这一推测。

 

二、

揭开内存的神秘面纱

  首先,我们看一下测试环境和生产环境的资源配置。可以看出测试环境单台虚拟机的配置(CPU内存)是生产环境的1/2,这也是内存不足的根源,下面围绕内存设计三个场景的测试。

 

场景一:疲劳测试发生问题的场景。

  JVM堆内存GC正常,虚拟机内存不足,使用了Swap分区。为了进一步确定Swap分区确实是被WAS使用 ,我们进入到/proc下WAS Server进程的目录,cd /proc/${WasServerPid},该目录下的smaps文件详细记录了该进程的内存使用情况,然后执行cat smaps | grep Swap | grep -v "0 kB" | sort -nr,便可查看进程对Swap的使用。通过查看,该WAS节点的Server1使用了538MB,Server2使用了574MB,加起来1G左右,这与此前监控的结果相符。而重启Server时,这两个值都是0,即未使用Swap分区。

 

场景二:每个节点只保留1个Server,JVM堆内存最大值为3G,虚拟机8G内存对于单Server完全够用。

  测试过程中,交易整体运行平稳,没有报错。JVM堆的分配值也是到达3G,然后通过GC循环使用。但由于只启动了一个Server,内存够用,没有使用到Swap分区,并且存在一定的富余。WAS的JVM堆内存和操作系统内存状态如图所示。

 

 转载于姚锴 马骁雄 51Testing软件测试网

分类:

技术点:

相关文章: