小研究 - J2EE 应用服务器的软件老化测试研究

软件老化现象是影响软件可靠性的重要因素，长期运行的软件系统存在软件老化现象，这将影响整个业务系统的正常运行，给企事业单位带来无可估量的经济损失。软件老化出现的主要原因是操作系统资源消耗殆尽，导致应用系统的性能下降甚至崩溃或宕机。文中监测J2EE 应用服务器系统资源的使用情况，考虑外界的负载变化，检测系统中软件老化现象，分析系统资源消耗何时达到临界值，从而帮助软件工程人员及时采取预维护手段，预防运行时系中重大故障的发生。

1 引言

2 J2EE 应用服务器老化测试和分析

2.1 实验环境

2.2 J2EE 应用服务器的老化测试

3 结束语

1 引言

大型软件系统在持续平稳运行一段时间之后，系统资源大量消耗，服务性能和质量下降甚至挂起或宕机，称为软件老化现象。软件老化可能造成安全关键系统的重大损失，甚至人员伤亡。引起软件老化的原因有内存泄漏、各种类型的逻辑错误、致命的安全缺陷、死锁、状态冲突等。

目前，很多计算系统中已经检测到软件老化现象。文件系统中存在软件老化现象，发现存储空间碎片较多的文件系统存取吞吐量较正常情况下降低 40%。文献中，第一次提出了基于测量方法估测软件老化情况，首先监测导致系统低效或宕机的资源，如内存使用、交换区使用、CPU 占用率、空闲通信通道等，然后用统计学模型估算和验证软件老化，根据不同的策略决定是否及何时进行软件维护。文献中，采用统计模式识别方法，检测在线事务处理服务器系统中的软件老化现象。文中，以响应时间和响应率为系统性能的衡量依据，考虑负载变化因素，提出 Web 服务器系统中软件老化的检测方法。文献中，通过收集 Apache Web 服务器中对换区数据、内存使用量以及响应时间等信息，利用非参数统计学方法进行老化预测。通过收集 Web 服务器中的资源使用参数，发现系统性能逐步下降，然后计算系统平均负载时间序列的最大李亚普诺夫指数，证明系统的老化现象具有混沌性。针对 SunHotSpot Java 虚拟机系统，考察系统负载对老化的影响以及系统内存资源和吞吐量的变化，采用统计分析的方法评估系统的老化趋势。一种基于AOP(Aspect － Oriented Programming)技术的系统性能监测机制，通过监测服务器系统中每个组件的资源使用情况，从而分析判定引起软件老化的组件。文献分析并研究云计算系统中存在软件老化现象的影响因素，通过监测系统虚拟内存和物理内存的使用情况，发现系统内存资源逐渐消耗、CPU 占有量逐步增加，并且系统响应时间随之增长。此外，常用软件如Netscape 和 XＲN 中也存在软件老化现象。

2 J2EE 架构的应用服务器系统

应用服务器是中间件最大的一个分支，其基于组件的中间层集成框架，为组件的运行提供运行时环境、基础服务和管理等功能。应用服务器位于企业应用与操作系统之间，屏蔽底层操作系统、网络以及数据库的异构性和复杂性，通过组件容器方式提供应用部署、运行平台。图 1 是一个基于 J2EE 平台的应用服务器结构示意图。客户端向应用服务器端提交服务请求，负载分配器根据服务请求的类型分配到合适的 HTTP 服务器上，然后将服务请求转交给应用服务器上，该应用服务器查询数据库，分析处理服务请求后将结果返回给客户端。J2EE 架构的应用服务器建立在 JVM(Java虚拟机)之上，JVM 的内存泄露是导致应用服务器老化的一个重要原因，因此需要对 JVM 的内存管理与内存泄漏进行分析。

JVM 内存区域，也叫运行时数据区，分为方法区、堆、栈、寄存器、本地码栈，在 JVM 运行程序时，存储字节码、对象、参数、返回值局部变量以及中间结果等数据。内存堆用来存放 Java 程序运行时创建的类实例或数组。每个虚拟机实例中只存在一个堆空间。JVM可以为新对象分配内存，但释放内存的任务由垃圾回收机制完成。垃圾回收机制回收不再被引用的无用对象，即当一个对象不再被引用的时候，内存回收它占用的空间，以便腾出空间被后来的新对象使用。但是有些可达的无用对象也可能成为不能回收的垃圾对象，如图 2 所示，垃圾回收机制这种潜在的缺陷造成内存泄漏的出现。

内存泄漏问题如果不加解决，随着时间的积累，造成 JVM 的内存使用量的持续增加，当 JVM 内存使用达到其最大堆栈大小时，JVM 自动的垃圾回收机制会进行垃圾收集。但每次执行垃圾收集后，无用对象所占的内存释放的百分比相对较小，最终会导致 JVM 连续地进行垃圾回收，占用大量的 CPU 时间，即 CPU 使用率持续增加。而系统资源是有限的，JVM 内存和 CPU使用率持续增加，最终将导致系统低效或宕机等老化现象。因此，需要专门的工具来实现 JVM 内存监测，提取内存相关信息，程序开发者能比较容易地判断程序是否有内存泄漏及其产生的原由，从而更好地进行软件老化现象的分析。

2 J2EE 应用服务器老化测试和分析

2.1 实验环境

测试的实验环境包括 J2EE 应用服务器和数据库服务器，运行在同一个局域网内，通过 100 Mbps 局域网连接，每个机器的配置为 P4 2． 4 G Intel CPU，运行环境采用 Sun JDK Hotspot 1． 4． 1_02 － b06。测试时首先在 IBM 的应用服务器 Websphere Application Server5． 1 上部署测试用例 Petstore 1． 3． 1 － 02，同时模拟多用户请求的应用客户端远程调用 EJB 模块中业务逻辑方法，业务逻辑方法包括了对数据库服务器中的数据的增加、删除、更新等操作，数据库系统是 IBM 的CloudScape4． 0。客户端负载发生器开始发送 SOAP/HTTP 服务请求时，在客户端实时地记录响应时间等系统性能参数信息，同时激活服务器端 Tivoli 性能查看器，记录应用服务器动态参数，基本的调用过程如图3 所示。负载发生器尽量模拟用户真实情况，采用一个星期为一个周期的形式，区分实际情况工作日和休息日的各个时段负载密度不同，模拟客户在某个小时间段内服从泊松分布，产生泊松序列的种子可自己设定。

数据采集工具使用 WAS 自带的 Tivoli 性能查看器(Tivoli Performance Viewer)，它可以监控系统资源的使用情况，也可以从 WAS 内部获取 J2EE 架构的服务器中相关参数。采集的数据来自四个模块:JVM 运行时模块，提取 JVM 内存的总大小和使用内存的大小;系统数据模块，提取 CPU 使用率和系统可用内存;Web 线程模块，提取创建的线程总数、破坏的线程总数、并发活动的线程数及线程池的大小;事务管理器，提取开始的全局事务、活动的全局事务、全局事务持续时间及全局事务回滚等。其中，JVM 运行时模块和系统数据模块是最为重要的两个模块。Tivoli 性能查看器和 WAS 同时运行在应用服务器上，占用系统部分资源，采用这种方法得到的老化预测模型实际上是数据采集软件和 J2EE 应用服务器的老化现象叠加。由于Tivoli 性能查看器占用的系统资源很少，影响程度可以忽略，可把结果看作是 J2EE 应用服务器老化的结果。

2.2 J2EE 应用服务器的老化测试

为了测试 J2EE 应用服务器中是否存在软件老化现象，分析导致应用服务器老化的原因，设计了不同强度的负载情况，监测应用服务器的运行时参数情况，并进行老化分析。这里，单位时间发送请求的数量和平均服务持续时间是影响负载强度的两个重要因素。应用服务器的负载峰值是指应用服务器在单位时间内能够响应的最大用户数量。首先在较短周期内向服务器发送等值强度的请求任务，同时在客户端记录响应时间等参数信息，若客户端的请求全部得到响应，则增加负载强度，直到出现应用服务器无法响应所有请求时停止，此时的负载强度即为负载峰值。在老化测试时，根据服务器负载峰值设计发送请求的负载强度。

1)重负载测试。

重负载测试中，平均负载强度设定为负载峰值的30%，其中负载任务高峰期时的负载强度设定为负载峰值的 50%。JVM 内存使用量的初始大小为 128 M，最大值为 256 M。如图 4 所示，随着系统运行时间的推移，应用服务器系统内存使用量逐步增加，最终系统在运行 43 小时后，JVM 内存使用量临近 256 MB，导致JVM 内存资源不足而出现宕机，此时系统无法响应客户端请求。图 4 中内存使用量变化呈锯齿状，是 JVM垃圾回收机制作用的结果，当可用内存出现暂时不足，不能满足程序的内存需求时，系统将自动调用垃圾回收机制，释放更多的可用内存空间。然而，随着应用服务器的长期运行，其性能不断下降，JVM 自动内存管理机制所起的作用越来越小，最终导致系统宕机。

为验证应用服务器是否存在老化现象，即系统性能是否随时间的推移而缓慢下降，采用一元线性回归方法，分析 JVM 内存使用量 Y(单位:kB)和应用服务器运行时间 X(单位:min)的关系，得到式(1)描述的拟合直线方程。