目录
1.总述 (2)
1.1JProfiler安装配置和使用说明 (2)
1.2JProfiler安装准备 (2)
1.3安装介质 (2)
1.4序列号 (3)
2.JProfiler Windows端安装与配置 (3)
2.1安装 (3)
2.2运行JProfiler并进行配置 (3)
2.3Linux上Weblogic Server配置 (5)
3.案例分析 (8)
3.1问题描述 (8)
3.2Web应用服务器的物理部署 (9)
3.3Web应用服务器启动脚本中的内存参数 (9)
3.4Web应用服务器的重要部署参数 (9)
3.5实例详细分析 (10)
4.总结 (26)
1.总述
在中间件应用服务器的整体调优中，有关于等待队列、执行线程，EJB池以及数据库连接池和Statement Cache方面的调优，这些都属于系统参数方面的调优，本文主要从另外一个角度，也就是从应用的角度来解决中间件应用服务器的内存泄露问题，从这个角度来提高系统的稳定性和性能。
1.1JProfiler安装配置和使用说明
JProfiler是一个全功能的Java剖析工具（profiler），专用于分析J2SE和J2EE应用程序。JProfiler直觉式的GUI让你可以找到性能瓶颈、抓出内存泄漏(memory leaks)、并解决多线程的问题。通过它可以对heap walker作资源回收器的root analysis，可以轻易找出内存漏失；heap快照（snapshot）模式让未被参照（reference）的对象、稍微被参照的对象、或在终结（finalization）队列的对象都会被移除。
1.2JProfiler安装准备
1.3安装介质
Jprofiler5.1.4目前支持的操作系统包括：aix-ppc、aix-ppc64、hpux-parisc、hpux-parisc64、linux-x64、linux-x86、windows、windows-64。安装介质见附件（一）。
1.4序列号
Name: any
Company: any
License Key:
L-Larry_Lau@https://www.doczj.com/doc/c04555390.html,#16320-dvzxpt17ogmau#013
L-Larry_Lau@https://www.doczj.com/doc/c04555390.html,#83851-1vyctfjv8d6ua#255
L-Larry_Lau@https://www.doczj.com/doc/c04555390.html,#83192-56yozpwn6v3n#174
2.JProfilerWindows端安装与配置
2.1安装
在 windows下直接解压zip包，运行jprofiler5.1.4的exe安装即可。
2.2运行JProfiler并进行配置
1）Quick Start:
选择 An application server, locally or remotely
->Next
2）Choose integration wizard
选择 BEA Weblogic 10.x
3）Local or remote:
The profiled applications located 选择On a remote
computer,
Platform of the remote computer 下拉菜单选择“Linux X86/AMD64”
->Next
4）Remote address :填写被监控应用程序所在远程计算机的IP:128.192.146.8
5）Installation directory:解压路径：/home/newcmsp/jprofiler5
6）Please locate the start script for BEA Weblogic 10.x 首先将128.192.146.8机器的/home/newcmsp/domains/cmsDomain/
bin/startWeblogic.sh 下载到windows端的目录下C:\Inetpub\ftproot，然后选择该文件。
7) choose JVM :
JVM Vendor: Sun jvm提供商
Version:1.6.0 版本
Mode：hotspot 系统默认
128.192.146.8机器是64位机器，在这里勾选64 bit JVM
8）jprofile port :8849 默认端口
9）startup mode:
Wait for ……为了在开发环境中获取监控的信息，它将等待远程计算机上的Jprofile GUI 启动，并和本机建立连接，这种方式
比较便于修改jprofiler的配置信息。
Don't wait for ……不必等待远程计算机的Jprofile GUI 先启动和建立连接，立即启动。但在启动远程应用程序前必须校验当前所配置会话的配置文件。虚拟机参数将参考Jprofile 的config 文件的路径。
这里选择Wait for ……
->Next->Finished.
10）在C:\Inetpub\ftproot目录下生成startWebLogic_jprofiler.sh文件，检查一下内容：
LD_LIBRARY_PATH="/home/newcmsp/jprofiler5/bin/linux-x64 :$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH
JPROFILER_OPTIONS="-agentlib:jprofilerti=port=8849
-Xbootclasspath/a:/home/newcmsp/jprofiler5/bin/agent.jar $JPROFILER_OPTIONS"
export JPROFILER_OPTIONS
2.3Linux上Weblogic Server配置
将startWebLogic_jprofiler.sh拷贝到weblogic的启动目录下/home/newcmsp/domains/cmsDomain/bin。通过shstartWebLogic_jprofiler.sh命令启动weblogic即可。
sh startWebLogic_jprofiler.sh
.JAVA Memory arguments: -Xms2048m -Xmx2048m -XX:CompileThreshold=8000 -XX:PermSize=2048m -XX:MaxPermSize=2048m
.WLS Start Mode=Development
.CLASSPATH=/home/mw/weblogic/bea/patch_wls1036/profiles/def ault/sys_manifest_classpath/weblogic_patch.jar:/home/mw/web logic/bea/patch_ocp371/profiles/default/sys_manifest_classp ath/weblogic_patch.jar:/opt/jdk1.6.0_30/lib/tools.jar:/home
/mw/weblogic/bea/wls1036/server/lib/weblogic_sp.jar:/home/m
w/weblogic/bea/wls1036/server/lib/weblogic.jar:/home/mw/web logic/bea/modules/features/weblogic.server.modules_10.3.6.0
.jar:/home/mw/weblogic/bea/wls1036/server/lib/webservices.j ar:/home/mw/weblogic/bea/modules/org.apache.ant_1.7.1/lib/a
nt-all.jar:/home/mw/weblogic/bea/modules/net.sf.antcontrib_ 1.1.0.0_1-0b2/lib/ant-contrib.jar:/home/mw/weblogic/bea/wls 1036/common/derby/lib/derbyclient.jar:/home/mw/weblogic/bea
/wls1036/server/lib/xqrl.jar:/home/ap/sa/sa1.0/lib64:.
PATH=/home/mw/weblogic/bea/wls1036/server/bin:/home/mw/webl ogic/bea/modules/org.apache.ant_1.7.1/bin:/opt/jdk1.6.0_30/ jre/bin:/opt/jdk1.6.0_30/bin:/usr/lib64/qt-3.3/bin:/usr/ker beros/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/ usr/local/sbin:/usr/sbin:/sbin:/home/newcmsp/bin
.
***************************************************
* To start WebLogic Server, use a username and *
* password assigned to an admin-level user. For *
* server administration, use the WebLogic Server *
* console at http://hostname:port/console *
***************************************************
starting weblogic with Java version:
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Starting WLS with line:
/opt/jdk1.6.0_30/bin/java -agentlib:jprofilerti=port=8849 -Xbootclasspath/a:/home/newcmsp/jprofiler5/bin/agent.jar
-Xms2048m -Xmx2048m -XX:CompileThreshold=8000 -XX:PermSize=2048m -XX:MaxPermSize=2048m https://www.doczj.com/doc/c04555390.html,=AdminServer
-Djava.security.policy=/home/mw/weblogic/bea/wls1036/server
/lib/weblogic.policy -Xverify:none -da -Dplatform.home=/home/mw/weblogic/bea/wls1036
-Dwls.home=/home/mw/weblogic/bea/wls1036/server
-Dweblogic.home=/home/mw/weblogic/bea/wls1036/server
-Dweblogic.management.discover=true -Dwlw.iterativeDev= -Dwlw.testConsole= -Dwlw.logErrorsToConsole= -Dweblogic.ext.dirs=/home/mw/weblogic/bea/patch_wls1036/pro files/default/sysext_manifest_classpath:/home/mw/weblogic/b ea/patch_ocp371/profiles/default/sysext_manifest_classpath weblogic.Server
JProfiler> Protocol version 25
JProfiler> Using JVMTI
JProfiler> 64-bit library
JProfiler> Listening on port: 8849.
JProfiler> Native library initialized
JProfiler> Waiting for a connection from the JProfiler GUI ...
3.案例分析
3.1问题描述
某个大型项目，在项目上线后，其Web应用服务器经常宕机。表现为：1. 应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位；
2. 应用服务器极为不稳定，几乎每两天重新启动一次，有时甚至每天重新启动一次；
3. 应用服务器经常做Full GC(Garbage Collection)，而且时间很长，大约需要30-40秒，应用服务器在做Full GC的时候是不响应客户的交易请求的，非常影响系统性能。
3.2Web应用服务器的物理部署
一台Unix服务器（4CPU，8G Memory）来部署本Web应用程序；Web应用程序部署在中间件应用服务器上；部署了一个节点（Node），只配置一个应用服务器实例（Instance），没有做Cluster部署。
3.3Web应用服务器启动脚本中的内存参数
可以看出目前生产系统中Web应用服务器的内存分配为3G Memory。
3.4Web应用服务器的重要部署参数
3.5实例详细分析
内存长期占用并导致系统不稳定一般有两种可能：
1. 对象被大量创建而且被缓存，在旧的对象释放前又有大量新的对
象被创建使得内存长期高位占用。
?表现为：内存不断被消耗、在高位时也很难回归到低位，有大量的对象在不断的创建，经过很长时间后又被回收。例如：在
HttpSession中保存了大量的分页查询数据，而HttpSession的会话超时时间设置过长（例如：1天），那么在旧的对象释放前又有大量新的对象在第二天产生。
?解决办法：对共享的对象可以采用池机制进行缓存，避免各自创建；
缓存的临时对象应该及时释放；另一种办法是扩大系统的内存容量。
2. 另一种情况就是内存泄漏问题
?表现为：内存回收低位点不断升高（以每次内存回收的最低点连成一条直线，那么它是一条上升线）；内存回收的频率也越来越高，内存占用也越来越高，最终出现"Out of Memory Exception"的系统异常。
?解决办法：定位那些有内存泄漏的类或对象并修改完善这些类以避免内存泄漏。方法是：经过一段时间的测试、监控，如果某个类的对象数目屡创新高，即使在JVM Full GC后仍然数目降不下来，这些对象基本上是属于内存泄漏的对象了。
问题定位
这里请看5月份 Web应用服务器的内存回收图形：
《注意：5月18日早上10点重新启动了Web服务器，5月20日早上又重新启动了Web服务器。》
?在Web应用重要部署参数中，我们知道：Session的超时时间为4个小时，我们在监控平台也观测到：在18日晚上10点左右所有的会话都过期了，从图形一中也能看出18日晚上确实系统的内存有回收到40%（就象股票的高位跳水）；
?从图形一（5月18日）中我们也能看到Full GC回收后的内存占用率走势（红色曲线），上午基本平滑上升到20%（内存占用率），中午开始上升到30%，下午上升到40%
?从图形二（5月19日）中我们也能看到Full GC回收后的内存占用率走势（红色曲线），上午又上升到了60%，到下午上升到了70%。?从黄色曲线（GC花费的时间，以秒为单位），Full GC的频率也在增快，时间耗费也越来越长，在图形一中基本高位在20秒左右，到19日基本都是30-40秒之间了。
图形一 5月18日
图二
通过上述分析，我们基本定位到了Web应用服务器的内存在高位长期占用的原因了：是内存泄露！并且正是由于这个原因导致系统不稳定、响应客户请求越来越慢的。
解决方法
方法如下：
?我们从图形二中发现，在8.95(将近9点钟)到9.66（将近9点40）期间有几次Full GC，但是有内存泄漏，从占用率40%上升到50%左右，泄漏了大约10%的内存，约300M；
?我们在自己搭建的Web应用服务器平台（应用软件版本和生产版本一致）做这一阶段相同的查询交易；表明对同一个黑盒（Web应用）施加同样的刺激（同一用户做相同的操作过程和查询交易）以期重现现象；
?我们使用Jprofiler工具对Web应用服务器的内存进行实时监控；?做完这些交易后，用户退出系统，并等待Web应用服务器的HttpSession超时（我们这里设置为15分钟）；
?我们对Web应用服务器做了两次强制性的内存回收操作。
发现如下：
如图三所示，内存经过HttpSession超时后，并强制gc后，仍然有大量的对象没有释放。例如：
https://www.doczj.com/doc/c04555390.html,m.security.MenuNode，仍然有807个实例没有释放。
我们继续追溯发现，这些MenuNode首先存放在一个ArrayList对象中，然后发现这个ArrayList对象又是存放在WHsessionAttrVO对象的Map中，WHsessionAttrVO 对象又是存放在ExternalSessionManager的staic Map中（名称为sessionMap），如图四所示。
我们发现https://www.doczj.com/doc/c04555390.html,m.WHsessionAttrVO 中保存了EJBSessionId信息(登录用户的唯一标志，由用户id+登录时间戳组成，每天都不同)和一个HashMap，这个HashMap中的内容有：
?ArrayList: 内有MenuTreeNodes（菜单树节点）
?HashMap: 内有操作人员代码信息
?CurrentVersion:当前版本号
?CurrentTime:当前系统时间
WHsessionAttrVO这个对象的最终存放在ExternalSessionManager 的static Map sessionMap中，由于ExternalSessionManager是一个全局的单实例，不会释放，所以它的成员变量sessionMap中的数据也不会释放，而Map中的Key值为EJBSessionId，每天登录的用
户EJBSessionId都不同，就造成了每天的登录信息（包括菜单信息）都保存在sessionMap中不会被释放，最终造成了内存的泄漏。
图五
如上图所示：WHsessionAttrsVO对象中除了有一个String对象（内容是EJBSessionId），还有一个HashMap对象。
图六
如上图所示，这个HashMap中的内容主要有menuTreeNodes为key，value为ArrayList的对象和以czrydminfo为key，value为HashMap 对象的数据。
图七
如上图所示：menuTreeNodes为key，value为ArrayList对象中包含的对象有许多的MenuNode对象，封装的都是用户的菜单节点。图八
如上图所示，最顶层（Root）的初始对象为一个ExternalSessionManager对象，其中的一个成员变量为static (静态的)，名称为：sessionMap，这个对象是singleton方式的，全局只有一个。
初步估量
我们从图形一和图形二中可以看出，每天应用服务器损失大约40%的内存，大约1G左右。
从图形四可以看出，当前用户（Id=24400001129）有807个菜单项（每个菜单项为一个MenuNode 对象实例，图形四中的这个实例的size
为592 Byte），这些菜单数据和用户基本登录信息（czrydmInfoHashMap）也都存放在WHsessionAttrVO对象中，当前这个WHsessionAttrVO对象的size为466KB（592×807÷1024）
我们做如下估算：
假设平均每天有4千人（估计值，这个数值仅仅是5月19日峰值的1/2左右）登录系统（有重复登录的现象，例如：上午登录一次，中午退出系统，下午登录一次），以平均每人占用200K（估计值，是用户id=24400001129 的Size的1/2左右）来计算，一天泄漏的内存约800M，比较符合目前内存泄漏的情况。当然，这种估计仍然需要经过实践的检验，方法是：当这次发现的内存泄漏问题解决后看系统是否还有其它内存泄漏问题。
方案
ExternalSessionManager类是用来解决Web服务器负载均衡的模块，这个类主要用来保存客户的基本登录信息（包括会话的EJBSessionId），以维护多个Web服务器之间的会话信息一致。
改进方案有两种：
?从架构设计方面改进
实现Web层的负载均衡有很多标准的实现方式。例如：采用负载均衡设备(硬件或软件)来实现。
如果采用新的Web层的负载均衡方式，那么就可以去掉
ExternalSessionManager这个类了。
?从应用实现方面改进
保留当前的Web层的负载均衡设计机制，仅仅从应用实现方面解决内存泄漏问题，首先菜单信息不应该保存在
ExternalSessionManager中。其次，增加对
ExternalSessionManager类中用户会话登录信息的清除，有几种方式可以选择：
?被动方式，当HttpSession会话超时（或过期）被Web应用服务器回收时清除相应的ExternalSessionManager中的过期会话登录信息。
?主动方式，可以采用任务定时清理每天的过期会话登录信息或线程轮询清理。
?采用新的会话登录信息存储方式，ExternalSessionManager的sessionMap中的key值不再以EJBSessionId作为键值，而是以
用户id（EJBSessionId的前11位）代替。由于用户id每天都是一样的，所以不会造成内存泄漏。保存得登录信息也不再包含菜单节点信息，而只是登录基本信息。最多也只是保存整个系统所有的用户id及其基本登录信息（大约每个用户的登录信息只有1.5K左右，而目前这个系统的营业网点用户为1万左右，所以大约只占用Web服务器15M内存）。
实施情况
采用的方案：本次采用了新的会话登录信息存贮方案，
即:ExternalSessionManager的成员变量sessionMap中不再保存用户菜单信息，只保存基本的登录信息；存储方式采用用户id（11位）作为键值（key）来保留用户基本登录信息。
基本分析：由于基本登录信息只有1K左右，而目前内网登录的用户总数也只有8887个，所以只保存了大约10M-15M的信息在内存，占用量很小，并且不会有内存泄漏。用户菜单信息保存在session中，如果用户退出时点击logout页面，那么应用服务器可以很快地释放这部分内存；如果用户直接关闭窗口，那么保存在session中的菜单信息只有等会话超时后才会由系统清除并回收内存。
监控状况：