性能测试WAS内存使用的探索和分析

　　性能测试中，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堆内存和操作系统内存状态如图所示。