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

Posted 2021-04-28 我们的开心

文/姚锴 马骁雄

性能测试中，CPU和内存是受关注最多的两个性能指标。以我行应用最多的系统架构（WAS+Oracle）来说，CPU使用率高的问题多发生于数据库，比如索引不当引发的表扫描、绑定变量使用不当引发的硬解析、连接池使用不当引发的频繁建立断开连接，这些都会导致数据库服务器CPU使用率高。内存问题则多发生于应用服务器。部署在WAS平台的Java应用，经常发生的问题是JVM堆内存溢出。产生该问题的原因有很多：由环境引发的，虚拟机物理内存不足；由参数配置引发的，JVM堆内存设置过小；由应用程序引发的，内存泄露，错误使用大对象等等。在实际性能测试过程中选择监控指标时，对JVM堆内存的监控分析比对操作系统内存的分析更为重要。

JVM堆内存溢出的原因中，虚拟机物理内存不足常常被忽视。本文结合项目测试过程中发现的由内存不足引发的性能问题，设计几个场景来探索JVM堆内存和虚拟机内存之间的影响关系。

Part.1

莫名其妙的“会话超时”

在某交易（登录+查询+退出）的疲劳场景中，发现应用服务器内存使用率超过90%，且被测交易存在大量报错：用户未登录或已超时，请登录。

WAS中会话相关的两个参数，最大内存中会话数1000和会话超时30分钟。性能测试场景中，会话数使用不到1000，且登录之后并没有退出，也不会发生用户未登录或已超时。所以，报错的原因在哪里？

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

JVM堆内存状态

操作系统内存状态

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

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

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

Part.2

揭开内存的神秘面纱

首先，我们看一下测试环境和生产环境的资源配置。可以看出测试环境单台虚拟机的配置（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内存

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

场景三：每个节点启动2个Server，JVM堆内存最大值为3G，虚拟机8G内存

与场景一不同的是关闭Swap分区，验证物理内存不足、无Swap分区可用的情况下系统的表现。

Linux的内存管理通过一个swappiness的内核参数，来调整使用Swap分区的积极程度。该参数的范围是0-100，数值越低，就会让Linux尽量少用Swap分区，多用内存；数值越高，就会越积极使用Swap分区。

使用sysctl vm.swappiness=0命令来临时修改；在/etc/sysctl.conf文件中编辑vm.swappiness=0并执行sysctl -p进行永久修改；使用cat /proc/sys/vm/swappiness查看系统当前值。在测试环境的SLES 11 SP4中，swappiness的默认值是60，如下图所示。

将swappiness设置为0，没有产生显著的效果，仍然使用到了Swap分区，发生了和场景一同样的现象。我们采取更为直接的方法，将Swap分区挂载的磁盘umount，这样Swap分区没有了物理载体，操作系统就无法使用Swap分区了。执行umount操作后，系统内存状态如下表所示，可以看到Swap分区的大小是0。

该场景下，交易没有报错，但是发生了Server宕的现象。此时虚拟机的内存状态如下，内存使用率达到94%。

使用工具分析GC日志文件native_stderr.log，查看详细的GC过程，如下图。蓝色的线是JVM堆内存当前值，红色的线是JVM堆内存已使用值。当JVM向操作系统申请内存，但是又申请不到（内存不足，Swap分区已关闭），蓝色的线触及3G后不久，发生了Server重启现象（灰色的菱形）。

对比三个场景的测试结果，首先JVM向操作系统申请一定的内存，如果当前的JVM堆内存不满足使用需求，JVM继续向操作系统申请内存（但申请的最大值不能超过最大堆大小）。如果虚拟机内存充足，则程序正常运行，此为场景二；如果虚拟机内存不足，但可以使用Swap分区，则程序仍能运行，但是由于IO的影响，会出现一些问题，如会话超时，此为场景一；如果虚拟机内存不足，且没有Swap分区可用，则内存溢出，Server宕，此为场景三。

对于生产环境的配置，每台虚拟机的配置为8C16G，每个节点有2个Server，每个Server的最大堆大小为3G。虚拟机内存是充足的，因此生产上不会出现场景一和场景三的现象，程序稳定运行。

JVM堆内存相关有两个参数：初始堆大小和最大堆大小。其中，最重要的参数是最大堆大小，代表JVM向操作系统申请的最大内存。登录WAS管理控制台进行查看和设置，路径为：应用程序服务器 > Node-xxxx-server1 > 进程定义 > Java 虚拟机。修改JVM堆参数后，需要重启Server生效。

需要注意的是，WAS集群中除了Server之外 ，还有dmgr进程和nodeagent进程也会占用一定的内存。dmgr进程是WAS管理控制台的后台进程，我们在管理控制台里做的各种操作，如配置参数、重启集群、部署程序，均是通过dmgr进程，将各种指令通过nodeagent传达到各个Server。dmgr堆内存设置过小的直接影响是，管理控制台响应缓慢，有时甚至直接宕掉。对于一些应用程序包较大、集群节点较多的WAS，需要给dmgr配置较大的堆内存，有时可以将dmgr单独部署在一个虚拟机上，和nodeagent、server分开，避免互相争用内存。

Part.3

     总   结

回顾本次性能测试发生的问题（场景一），完全是由于测试环境虚拟机内存不足引起的，非程序本身的问题。在我们实际项目测试中，资源部门给我们分配的测试环境，可能存在硬件配置低、软件参数设置不合理的现象。然而这种环境配置的影响常常被我们所忽视。在执行性能测试之前，一定要确认环境的配置，包括虚拟机的内存，WAS各个进程（dmgr、nodeagent、server）的JVM堆内存配置。即便在最差情况，虚拟机内存不足又无法扩容，也要优先确保Server的JVM堆内存充足，因为Server是真正运行应用程序的进程。

轮值总编：王晓昕

责任编辑：侯健琦

美       编：侯健琦

技术支持：夏 露

我们的开心 · 总编辑部

（啄木鸟）

-  

快 乐 生 活 

开 心 工 作 

   

我 们 的 开 心

微信号：abc_kx

■ 本文为“我们的开心”第4017期文章  

■ 转载本号文章请联系我们

■欢迎来稿：请按“作品名-作者-部门”命名，发送到[e-mail]