??xml version="1.0" encoding="utf-8" standalone="yes"?>
某个大型目QUse Case用例过300个)Q在目上线后,其Web应用服务器经常宕机。表CؓQ?
1. 应用服务器内存长期不合理占用Q内存经常处于高位占用,很难回收C位;
2. 应用服务器极ZE_Q几乎每两天重新启动一ơ,有时甚至每天重新启动一ơ;
3. 应用服务器经常做Full GC(Garbage Collection)Q而且旉很长Q大U需?0-40U,应用服务器在做Full GC的时候是不响应客L交易h的,非常影响pȝ性能?
一台Unix服务器(4CPUQ?G MemoryQ来部v本Web应用E序QWeb应用E序部v在中间g应用服务器上Q部|了一个节点(NodeQ,只配|一个应用服务器实例QInstanceQ,没有做Cluster部v?
MEM_ARGS="-XX:MaxPermSize=128m -XX:MaxNewSize=512m -Xms3096m -Xmx3096m -XX:+Printetails -Xloggc:./inwebapp1/gc.$$" |
可以看出目前生pȝ中Web应用服务器的内存分配?G Memory?
参数名称 | 参数? | 参数解释 |
kernel.default(Thread Count) | 120 | 执行U程数目Q是q发处理能力的重要参? |
Session Timeout | 240分钟Q?时Q? | HttpSession会话时 |
内存长期占用q导致系l不E_一般有两种可能Q?
1. 对象被大量创且被缓存,在旧的对象释攑։又有大量新的对象被创Z得内存长期高位占用?
2. 另一U情况就是内存泄漏问?
q里L5月䆾 Web应用服务器的内存回收囑ŞQ?
《注意:5?8日早?0炚w新启动了Web服务器,5?0日早上又重新启动了Web服务器。?
通过上述分析Q我们基本定位到了Web应用服务器的内存在高位长期占用的原因了:是内存泄Ԍq且正是׃q个原因Dpȝ不稳定、响应客戯求越来越慢的?
Ҏ如下Q?
发现如下Q?
如图三所C,内存l过HttpSession时后,q强制gc后,仍然有大量的对象没有释放。例如:gov.gdlt.taxcore.comm.security.MenuNodeQ仍然有807个实例没有释放?
我们l箋q溯发现Q这些MenuNode首先存放在一个ArrayList对象中,然后发现q个ArrayList对象又是存放在WHsessionAttrVO对象的Map中,WHsessionAttrVO 对象又是存放在ExternalSessionManager的staic Map中(名称为sessionMapQ,如图四所C?
我们发现gov.gdlt.taxcore.taxevent.xtgl.comm.WHsessionAttrVO中保存了EJBSessionId信息(d用户的唯一标志Q由用户id+d旉戳组成,每天都不?和一个HashMapQ这个HashMap中的内容有:
WHsessionAttrVOq个对象的最l存攑֜ExternalSessionManager的static Map sessionMap中,׃ExternalSessionManager是一个全局的单实例Q不会释放,所以它的成员变量sessionMap中的数据也不会释放,而Map中的KeygؓEJBSessionIdQ每天登录的用户EJBSessionId都不同,造成了每天的d信息Q包括菜单信息)都保存在sessionMap中不会被释放Q最l造成了内存的泄漏?
如上图所C:WHsessionAttrsVO对象中除了有一个String对象Q内ҎEJBSessionIdQ,q有一个HashMap对象?
如上图所C,q个HashMap中的内容主要有menuTreeNodes为keyQvalue为ArrayList的对象和以czrydminfo为keyQvalue为HashMap对象的数据?
如上图所C:menuTreeNodes为keyQvalue为ArrayList对象中包含的对象有许多的MenuNode对象Q封装的都是用户的菜单节炏V?
如上图所C,最层QRootQ的初始对象Z个ExternalSessionManager对象Q其中的一个成员变量ؓstatic (静态的)Q名UCؓQsessionMapQ这个对象是singleton方式的,全局只有一个?
我们从图形一和图形二中可以看出,每天应用服务器损失大U?0%的内存,大约1G左右?
从图形四可以看出Q当前用PId=24400001129Q有807个菜单项Q每个菜单项Z个MenuNode 对象实例Q图形四中的q个实例的size?92 ByteQ,q些菜单数据和用户基本登录信息(czrydmInfo HashMapQ也都存攑֜WHsessionAttrVO对象中,当前q个WHsessionAttrVO对象的size?57K?
我们做如下估:
假设q_每天?千hQ估计|q个数g仅是5?9日峰值的1/2左右Q登录系l(有重复登录的现象Q例如:上午d一ơ,中午退出系l,下午d一ơ)Q以q_每h占用200KQ估计|是用户id=24400001129 的Size?/2左右Q来计算Q一天泄漏的内存U?00MQ比较符合目前内存泄漏的情况。当Ӟq种估计仍然需要经q实늚验,Ҏ是:当这ơ发现的内存泄漏问题解决后看pȝ是否q有其它内存泄漏问题?
![]() |
ExternalSessionManagercL当初某某软g商设计的用来解决Web服务器负载均衡的模块Q这个类主要用来保存客户的基本登录信息(包括会话的EJBSessionIdQ,以维护多个Web服务器之间的会话信息一致?
改进Ҏ有两U:
从架构设计方面改q?
实现Web层的负蝲均衡有很多标准的实现方式。例如:采用负蝲均衡讑֤(g或Y?来实现?
如果采用新的Web层的负蝲均衡方式Q那么就可以LExternalSessionManagerq个cM?
从应用实现方面改q?
保留当前的Web层的负蝲均衡设计机制Q仅仅从应用实现斚w解决内存泄漏问题Q首先菜单信息不应该保存在ExternalSessionManager中。其ơ,增加对ExternalSessionManagercM用户会话d信息的清除,有几U方式可以选择Q?
![]() |
采用的方案:某某软g商采用了新的会话d信息存贮ҎQ即:ExternalSessionManager的成员变量sessionMap中不再保存用戯单信息,只保存基本的d信息Q存储方式采用用户idQ?1位)作ؓ键|keyQ来保留用户基本d信息?
基本分析Q由于基本登录信息只?K左右Q而目前内|登录的用户L也只?887个,所以只保存了大U?0M-15M的信息在内存Q占用量很小Qƈ且不会有内存泄漏。用戯单信息保存在session中,如果用户退出时点击logout面Q那么应用服务器可以很快地释放这部分内存Q如果用L接关闭窗口,那么保存在session中的菜单信息只有{会话超时后才会ql清除ƈ回收内存?
监控状况Q?
如图九所C,ExternalSessionManager中只保留了简单的d信息QMap中保存了WHsessionAttrVO对象Q,包括Q当前版?currentversion)Q操作h员代码基本信息(czrydmInfoQ,当前旉QcurrenttimeQ?
如图十所C,q个d用户的基本信息只?368 bytesQ大U?.3K
如图十一所C,一共有两个用户Q相同的用户idQ登录系l,当一个用户用logout面退出时Q保留在session中的菜单信息(MenuNode)立刻释放了,所以Difference一栏减了806个菜单项?
如图十二所C,当另外一个会话超时后Q应用服务器回收了整个会话的菜单信息QMenuNodeQ,图上已经没有MenuNode对象了。ƈ且由于是同一个用L录,所以保留在ExternalSessionManager成员变量sessionMap中的对象WHsessionAttrVO只有一?id=24400001129)Q而没有生多个,没有因ؓ多次d而生多个对象的后果Q避免了内存泄漏问题的出玎ͼ解决了前期定位的内存泄漏问题?
如图十三所C,l过gc内存回收后,发现内存回收比较E_Q基本都回收C最低点Q也证明了内存没有泄霌Ӏ?
l论与徏议:从测试情늜Q解决了前期定位的内存泄漏问题?
生pȝ实施后的监控与分?/strong>
l过调优后,我们发现Q在2005q??日晚9?0左右重新部v、启动了Web应用服务器(采用了新的调优方案)。经q几天的监控q行Q发现Web应用服务器目前运行基本稳定,目前没有出现新的内存泄漏问题Q下列图C明了q一?
如图十四所C,6?日晚21.7Q?1?2分)重新启动应用服务器,内存占用很少Q大Uؓ15%Q请看红色曲U)Q每ơGC消耗的旉也很短,大约?U以内(L黄色曲线Q?
如图十五所C,??日周五的整个工作日内Q内存的回收基本CQ回收位|控制在20%-30%之间Q也是?00M-900M之间Q请看红色曲U的最低点Q,始终可以回收2G的内存供应用E序使用Q每ơGC的时间最高不过20U,Full GCq_?0U左叻I旉消耗比较短Q请看黄色曲U)?
如图十六所C,在周日休息日期间QWeb应用服务器全天只做了大约4ơFull GCQ黄色曲U中的小山峰Q,旉都在10U以内;大的Full GC后,内存只占?0%Q内存回收很d?
如图十七所C,在周一工作日期_内存回收q是不错的,基本可以回收?0%Q见U色曲线的最低点Q,卻I占用900M内存I间Q剩?G的内存空_Full GC的时间大部分控制?0U以内,q_15U(见黄色曲U)?
如图十八所C,??日周二早上,大约8:30左右QWeb应用服务器作了一ơFull GCQ用?0U的旉Q把内存回收C10%的位|,为后l的使用腑և?0%的内存空间。内存回收仍然比较彻底,说明基本没有内存泄漏问题?
l过q几天的监控分析Q我们可以看出:
![]() |
通过本文Q我们可以看刎ͼ内存的泄露将会导致服务器的宕机,pȝ性能更别说了。对于系l内存泄露问题应该从服务器GC日志斚wq行早诊断,使用工具早确认ƈ提出解决ҎQ排除内存泄露问题,提高pȝ性能Q以规避目风险?br />
本文转自Qhttp://yufeimen.javaeye.com/blog/70721
旉Q?/span> 2006/01/05
1、摘?.........................................................................1
2、改善服务器的性能...........................................................1
3、分析器原理...................................................................2
4、JProfiler ?..............................................................2
5、JProfiler 特征...............................................................3
6、本地监?....................................................................4
7、远E监?....................................................................7
8、参?.........................................................................9
改善 Java 服务器的性能需要模拟负载下的服务器。创Z个模拟环境、搜集数据ƈ且分析结果可能是对许多开发h员的挑战。这文章介l了使用 JProfiler 跟踪分析 Java 服务器的性能?/span>
单的性能问题很容易分dƈ解决Q然而,大的性能问题Q如内存溢出或者系l的|工Q通常在系l处于高负蝲情况下发生,׃能这么简单的处理了。这些问题需要一个独立的试环境、一个模拟的负蝲Qƈ且需要仔l地分析和跟t?/span>
在这文章中Q我使用比较通用的工P JProfiler ?/span> JBuilder Q和讑֤创徏了一个性能监控分析环境Q跟t本地和q程的服务器E序Q专注于三个性能问题Q内存、垃圑֛收和多线E运行状况,从而很好的监视 JVM q行情况及其性能?br />
服务器的性能改善是依赖于数据的。没有可靠的数据基础而更改应用或环境会导致更差的l果。分析器提供有用?/span> Java 服务器应用信息,但由于从单用戯载下的数据与多用戯载下得到的数据是完全不同的,q导致分析器的数据ƈ不精。在开发阶D用分析器来优化应用的性能是一个好的方式,但在高负载下的应用分析可以取到更好的效果?/span>
在负载下分析服务器应用的性能需要一些基本的元素Q?/span>
1?span style="font: 7pt 'Times New Roman'"> 可控的进行应用负载测试的环境?/span>
2?span style="font: 7pt 'Times New Roman'"> 可控的h造负载得应用满负荷q行?/span>
3?span style="font: 7pt 'Times New Roman'"> 来自监视器、应用和负蝲试工具自n的数据搜集?/span>
4?span style="font: 7pt 'Times New Roman'"> 性能改变的跟t?/span>
不要低估最后一个需求(性能跟踪Q的重要性因为如果不能跟t性能你就不能实际的管理项目。性能?/span> 10-20% 的改善对单用L境来说ƈ没有什么不同,但对支持人员来说׃一样了?/span> 20% 的改善是非常大的Q而且通过跟踪性能的改善,你可以提供重要的反馈和持l跟t?/span>
虽然性能跟踪很重要,但有时ؓ了后箋的测试更加精而不得不抛弃先前的测试结果。在性能试中,改善负蝲试的精性可能需要修Ҏ拟环境,而这些变化是必须的,通过变化前后的负载测试你可以观察到其中的转变?/span>
现在几乎所有的分析器都是从同一个v点和U束开始的Q?Java 虚拟机分析器界面 (JVMPI) ( 参?"The Java Virtual Machine Profiler Interface") ?Sun 微系l的 API 允许工具开发商接口或者连接到遵@ JVMPI ?JVM 上,q且监控q作的方式以?JVM q行M Java E序时的关键事g -- 从单独的应用E序?Applet ?Servlet 和企?JavaBeans (EJB) lg?
在分析器内启动一个程序意味着生成、捕捉、和观察大量数据Q所以所有的分析器都包含着不同的方法来控制数据的流动,在不同的标准以及每一装包的基础上进行过滤。同?也可以用灵zȝ正规表达式类型模式来完成?
是一个全功能?/span> Java 剖析工具Q?/span> profiler Q,专用于分?/span> J2SE ?/span> J2EE 应用E序。它?/span> CPU 、执行A和内存的剖析l合在一个强大的 应用中?/span> JProfiler 可提供许?/span> IDE 整合和应用服务器整合用途?/span> JProfiler 直觉式的 GUI 让你可以扑ֈ效能瓉、抓出内存漏?/span> (memory leaks) 、ƈ解决执行l的问题。它让你得以?/span> heap walker 作资源回收器?/span> root analysis Q可以轻易找出内存溢出; heap 快照Q?/span> snapshot Q模式让未被参照Q?/span> reference Q的对象、稍微被参照的对象、或在终l( finalization Q队列的对象 都会被移除;整合_以便剖析览器的 Java 外挂功能?/span>
目前最新的版本?/span> 4.1.2 Q几乎支持所有常用的 IDE ?/span> Application Server Q可以到?/span> EJ 官方|站 http://www.ej-technologies.com/ 下蝲Q申请一个十天的试用注册码?/span>
JProfiler 的内存视N分可以提供动态的内存使用状况更新视图和显C关于内存分配状况信息的视图。所有的视图都有几个聚集层ƈ且能够显C现有存在的对象和作为垃圑֛收的对象?/span>
在JProfiler的堆遍历?Heap walker)中,你可以对堆的状况q行快照q且可以通过选择步骤下寻找感兴趣的对象。堆遍历器有五个视图Q?/span>
JProfiler 提供不同的方法来记录讉K树以优化性能和细节。线E或者线E组以及U程状况可以被所有的视图选择。所有的视图都可以聚集到Ҏ、类、包或J2EElg{不同层上。CPU视图部分包括Q?/span>
对线E剖析,JProfiler提供以下视图:
观察JVM的内部状态,JProfiler提供了不同的遥感勘测视图Q如下所C?
pȝ环境 Windows OS QY?/span> JBuilderX/2005 ?/span> JProfiler 4.1.2
1 、安?/span> JBuilderX ?/span> JProfiler 4.1.2
2 、运?/span> JProfiler Q?/span> Session-> IDE integration tab, IDE 选择Borland JBuilder7 to 2005Q点击Integrate按钮Q选择JBuilder的安装目录,认Q会看到已经JProfiler以OpenTool的Ş式,成功整合到JBuilder中,见下图?/span>
3 、运?/span> JBuilder Q打开 Run->Configurations Q选择或新Z?/span> Runtime Q在 Optimize 选项中就可以看到 JProfiler Q可以选择每次q行E序新徏一?/span> JProfiler H口的提C|?/span>
4 、点?/span> Optimize Project 按钮Q运行程序?br />
5 、弹出如下的 JProfiler H口Q确认相关的信息卛_?br />
6 、至此,可以监控本地服务器的各个方面的性能了?br />
服务器程序一般运行在q程的服务器讑֤上,有时候我们还需要远E监控商用的服务器资源?/span>
服务器操作系l?/span> Linux OS Q安装步骤如下:
1?/jprofiler_linux_4_1_2.shQ出现如下提C:
testing JVM in /usr/jdk1.4 ...
Starting Installer ...
注:对于没有安装X Server的机器,需要执?/jprofiler_linux_4_1_2.sh -qQ否则会提示Q?br />
testing JVM in /usr/jdk1.4 ...
Starting Installer ...
This installer needs access to an X Server.
If this is not possible, you can run the installer in unattended mode
by passing the argument -q to the installer.
2、安装完毕后Q会?opt目录下,扑ֈjprofiler的安装目录,/opt/jprofiler4?/font>
本地操作pȝ WindowXP Q相关的配置如下Q?/span>
1 、本地安?/span> JProfiler Q?/span> Linux 服务器上也安?/span> JProfiler Q只有本?/span> / 监控者的需要输入序列号Q?/span>
2 、打开本地?/span> JProfiler Q?/span> session->Integration wizards-> New Remote integration
3 、选择 on a remote computer Q?/span> platform 选择 linux x86/AMD64 Q点?/span> next
4 、输入远E?/span> ip 地址Q点?/span> next
5 、输入远E?/span> JProfiler 的安装目录,默认都安装在 /opt/jprofiler4 下,一路NEXT
6 、出C面提C框Q按照要求配|下服务器的讄Q界面如下:
Java 执行语句中加入下列运行参?/span>
-Xint -Xrunjprofiler:port=8849 -Xbootclasspath/a:/opt/jprofiler4/bin/agent.jar Q?/span>
/etc/profile 中加?/span> export LD_LIBRARY_PATH=/opt/jprofiler4/bin/linux-x86 Q退出、重新登陆?/span>
7 、好了,全部配置完毕Q先q行q程服务器程序,再打开本地?/span> JProfiler E序Q握手成功后Q远E程序正常运行了?/span>
服务器信息如下:
[root@ns 55556]# tail -f nohup.out
JProfiler> Protocol version 21
JProfiler> Using JVMPI
JProfiler> 32-bit library
JProfiler> Listening on port: 8849.
JProfiler> Native library initialized
JProfiler> Waiting for a connection from the JProfiler GUI ...
// 以上为本?/span> JProfiler q上前的pȝ提示
JProfiler> Using dynamic instrumentation
JProfiler> Time measurement: elapsed time
JProfiler> CPU profiling enabled
JProfiler> Starting org/anymobile/server/cmwap/CmwapServer ...
2005/12/15 17:05:46 [ INFO] - Starting Cmwap Stand Server ...
2005/12/15 17:05:47 [ INFO] - HandleThread runing ......
如果你希望动态保存当?/span> Session 的运行数据的快照Q点?/span> JProfiler 的保存按钮即可;
可以通过 JProfiler Start Center ?/span> Open snapshot tab 打开保存?/span> Session Q?/span>
你也可以右键点击某个视图Q静态保存到 HTML 文gQ文字描q加视图囄Q?/span>
有一些视囄数据只会q行一ơ,不会动态的hQ如内存视图中的分配讉K树等视图Q?/span>
WinXP ?/span> JProfiler g不支持中文, 2K 下支持的Q上面有一些图片是?/span> 2K pȝ上截取的Q?/span>
另外Q?/span> JProfiler q可以监控某?/span> Application Server ?/span> Applet Q功能非常强大,可以参考Y件自带的 Help ?/span>
在Java的广泛应用中Q一个关键驱动因素是׃使用标准cd和应用框架从而提高了生效率。通过减少必要的设计,实现和调试等软g开发Q务,Java在各U^C间极大地改善了集成性和互操作性;其它的开发环境都不能提供象Java那样的强大功能。实际上Q没有一个环境象J2EE那样h明显的基于框架开发的优点QJ2EE能够快速地构徏可扩展,分布式的安全企业U应用?/p>
虽然q些优点一直在促进J2EE的空前发展,但也l常出现一些麻烦,那就是h们经常对J2EE应用的性能感到失望。因此,我们需要一些工具和调查{略来帮助J2EE开发团队解册些性能问题。这是Quest JProbe Profiler和Jprobe Memory Debugger所要解决的问题?/p>
一般情况下Q最l用户对J2EE应用性能的体验与下面层次是紧密相关的:
虽然毫无疑问Q底部层ơ会影响整个性能Q经验也不断地表明,性能下降的普遍原因是q成J2EE应用的ServletsQJSPs和EJBs的设计问题和不佳的实现造成的。本文将集中讨论在这个底层中如何识别出性能下降的原?/p>
本文描述了在BEA WebLogic Server6.1上下文环境中Q怎样用Quest JProbe Memory Debugger和Profiler分析J2EE应用。包括三个主要部?
Quest JProbe产品U由一族工L成,该族工具包括下面四个分析工具?/p>
虽然本文集中讨论了JProbe Memory Debugger和ProfilerQ但所有四个工具都采用了相同的体系l构设计Qƈ且与BEA WebLogic服务器的集成Ҏ是相同的?/p>
一个基于JProbe的调查会话由两个E序l成:
JProbe控制?/strong>是一个基于Swing的Java应用Q它提供了用户图形界面(GUIQ,用于建立调查会话Q在E序q行时查看分析信息和深入分析Snapshot文g中的信息内容?/p>
试型Java虚拟?/strong>-JProbe通过JVMPI(Java Virtual Machine Profiling Interface)提供的回调方法,使用标准的Java虚拟行Java应用q收集分析信息,该虚拟机是由厂商提供的。在剖析ZWLS的J2EE应用中,Java应用q行在Java虚拟ZQ该虚拟机由WebLogic服务器的基本框架l成Q就象J2EE应用部vC面一栗?/p>
q种l构h非常灉|的启动方式。你可以从用户图形界面本w启动测试型Java虚拟机,也可以单独启动测试型Java虚拟机ƈ且它连接上JProbe控制台?/p>
1. 启动JProbe Application Server Integration?/p>
2. 从左上角下拉列表中选择你要集成的BEA Weblogic服务器版本?/p>
3. 点击"Create"按钮。编辑窗口右边的内容Q如?所C?/p>
4. ~辑下面区域或用默认倹{?/p>
5. 点击"Advanced>>"按钮?/p>
6. 填写下面q区域?/p>
7. 点击"Save"按钮?/p>
?4 Q?JProbe Application Server Intergation H口 你已l成功创建和BEA Weblogic6.1的集成, 所有四个工具都可以使用q个集成q程?/p>
8. 点击"Close"按钮?/p>
JProbe Memory Debugger能帮助你q踪到游d象(loitering objectsQ和减少创徏q多的对象,q且JProbe Profiler能帮助你发现性能瓉。根据具体情况,需要具体分析。在q里Q我们简单地概括用于解决对象循环和性能瓉q两个常见问题的步骤。更多的信息和其它用JProbe Memory Debugger和Jprobe Profiler的方法,可以参考在U帮助或者阅读JProbe Memory Debugger Guide和JProbe Profiler Developer's Guide?/p>
Java应用性能下降的一个主要原因是创徏q多的对?(或称为对象@?。Java虚拟机分配了q多的内存,创徏了不必要的对象ƈ对这些对象的初始化,加大了垃圑֛收活动,从而引h能下降?/p>
作ؓ一个性能分析人员Q你首先需要识别出创徏大量短期对象的方法。这些方法是q一步做减少创徏对象数量分析的理惛_手点。。JProbe Memory Debugger提供的一个垃圄视功能可以把对象和分配它们的Ҏq接hQƈ且当你的应用q行Ӟ可以q踪有多对象已l被垃圾回收了?/p>
1. 启动JProbe Memory Debugger。当Ƣ迎界面出现的时候,点击"Run"开始启动?/p>
?5 Q?JProbe Ƣ迎界面 2. 在JProbe LaunchPadH口? aQ?选择"Using Application Server" bQ??Application Server"下拉的菜单中选择BEA Weblogic6.1 cQ?注意?Integration ID"下拉的菜单中填写JProbe Demo 1 3. 选择"Filter" aQ?点击"Please enter a packageQor method to display data for"。输入你要调查的?profiler.com.quoteme.stockwatch bQ??Display"栏的下拉菜单里选择"Display" 4. 选中"Monitor Garbage Collections from Program Start"复选框?/p>
5. 选择"Snapshot Directory:"为d:\temp?/p>
6. 点击"Run"按钮?/p>
?QJProbe LaunchPad PadH口 当WebLogic Server初始化时QRuntime Heap Graph增高,q反映了对象创徏和垃圑֛收活动。一旦WebLogic Server已经被充分初始化后,你就可以开始着手分析了?/p>
一旦WebLogic Server已经充分初始化,选择你想要用于分析对象@环的应用用例。选择Grabage Monitor标签Q按下面的步? 1. 首先q行一ơGarbage Collection Q回收在Java堆中分配的,但不再用的对象。Garbage Monitor表随时更新反映这些被回收对象的情c?/p>
2. 点击"Clear Table"清空Garbage Monitor表?/p>
3. q行你的应用用例。当Java虚拟机开始垃圑֛收时QGrabage Monitor表将随之更新?/p>
提示:在Heap Usage Chart中寻找负载峰倹{急剧升降的负载峰值意味着一些对象在被垃圑֛收之前只存活了很短的旉。连在一L一些急剧升降的负载峰值是一个明的信号Q意味着是一个对象@环问题?/p>
4. 在完成你应用用例后,再次q行Garbage Collection Q回收最后分配但不再使用的对象?/p>
当会话结束时QGarbage Monitor中包含了已回收最多实例的前十个类。通常Q这些类不是你自己应用的c,准确地说Q它们是被你的一些方?直接地或间接?分配的第三方的类。最后一列是分配q些已回收对象的Ҏ名?/p>
提示:如果被不同方法分配的实例属于同一个类Qƈ且都是前十个cȝ话,你将见到两行相同的类?/p>
1. 使用Filter Allocating MethodsQ只昄你包中的一些方法,屏蔽掉其它包中的Ҏ。在我们的例子中Q客户J2EE应用定义在profiler.com.quoteme.stockwatch包里面,所以我们把qo规范profiler.com.quoteme.stockwatch.*.*输入到Filter Allocating Methods文本输入控制中?/p>
2. 在GC'ed列中Q你能看C的方法分配了多少实例。作为比较,查看Alive列就能看到还有多实例仍在堆中。Java开发者通常会对创徏和移C多少对象而感到惊奇?/p>
3. 现在你已l识别到你有问题的方法。想想你可能怎样修改q些分配对象的方法,从而减或排除对象循环Q例如,你可以尝试重用某个对象或者创Z个可重用的对象池?/p>
4. WebLogic Server6.1~译JSP后,自动产生了一个servletcdQƈ赋予一个包名和cd。例如,如果有一个名为TestJSP.jsp的JSP文gQ将被编译成名ؓjsp_servlet.__testjsp的类(JSP名跟着两个下划U,q且都是写字母)?/p>
用Filtering Classes为jsp_servlet.*限制Garbage Monitor中的内容Q可以看到已l被垃圾回收到Garbage Monitor中的JSP。在Filtering Allocating Methods讄jsp_servlet.*.*或jsp_servlet._<你的JSP?gt;.* 限制Garbage Monitor中的内容Q可以从分配的角度在指定的JSP中查看垃圑֛收对象?/p>
更深入的研究 如果你分配的Ҏ没有一个出现在Garbage Monitor中,或者在修改明显的问题后Q仍然有对象循环的问题;你需要进行堆栈跟t,查哪个方法的调用D了创建实例ƈ分配了空间。需要用heap snapshot查看堆栈跟踪。要了解更多的信息,L在线帮助里的Garbage Collection Tutorial或?strong>JProbe Memory Debugger Developer's Guide 解决对象循环问题有助于性能的改q,但你可能仍然面着性能瓉。进行一ơ性能分析可帮助你在J2EE应用中识别低效率的算法。JProbe Profiler提供了应用的ҎU和源代码行U度量倹{?/p>
1. 启动JProbe Profiler。当Ƣ迎界面出现Ӟ点击"Run"开始? ?。JProbeƢ迎H口 2. 在JProbe LaunchPadH口? a. 选择"Using Application Server" b. 从Application Server下拉菜单中选择BEA Weblogic6.1 c. 注意在Integration ID下拉菜单中填JProbe Demo 1" 4. 选择Filter a. 点击Please enter a packageQclassQor method to display data for。输入你要调查的包profiler.com.quoteme.stockwatch d. 从Detail Level列的下拉菜单中选择Line Lever q个元素定义了我们想要把所有运行在环境中的Java软g看作基础l构。因为我们不惌l了解它们的性能信息 (我们只是想知道在代码上的影响Q我们不xl地分析) 提示:在WLS6.1中的JSP Profiling 当JSP被WebLogic Server6.1~译Ӟ产生的servlet被给予一个生的包和cd。例如,如果有一个名为TestJSP.jsp的JSP文gQ它被编译后Q生成名为jsp_servlet._testjsp的类(两个底线被JSP名跟着Q都是小写字??如果你想跟踪你的JSP里的Ҏ在执行中׃多少旉Q你必须指定正确的过滤策略,用于捕获数据? 5. 选择"CPU Time" 6. 选择"Record Performance at Program Start"复选框 7. 选择"a Snapshot Directory:"为d:\temp 8. 点击"Run"按钮 ?1?JProbe Profiler LaunchPadH口 在性能分析中,Heap Usage Chartp一个执行进度的监视器,与上节介l的Garbage Monitor不同Q这里不提供cM的运行时性能信息。WebLogic Server自己初始化到完全启动?/p>
作ؓ对象循环分析Q我们推荐用应用的,以用例ؓ中心的方法进行性能分析Q具体如? 1. 清空累积的性能数据 2. q行你的应用用例?/p>
3. 执行一ơ性能快照 性能快照包括旉和在用例q行期间对象创徏{度量数?q个q行期间从重新设|性能信息开?W一步,一直到执行快照l束Q第三步)?/p>
JProbe Profiler提供两个工具Q以不同的格式显C收集到的数据;可根据具体情况选择: 从Method List或Call Graph中,你能使用下面q些工具深入到更多的l节数据?/p>
JProbe Profiler在方法方面收集了三个基本度量? Method Objects是指该方法创建的对象L 在这些基本的度量值基上,JProbe Profiler计算ZU度量DC方法调用树: ZNumber of Calls用四U^均度量? 在默认情况下QCall Graph昄的数据是在性能快照中的数据。我们徏议你关闭Call Graph一会再打开Method ListH口?/p>
Method ListH口(见图12)以表的Ş式显C性能数据?/p>
?2。JProbe Profiler Method ListH口 每一行显CZҎ的时间和Ҏ创徏对象的度量倹{用Method List能很快识别你最耗时的方法。通常你会发现你的性能瓉和这些方法有兟?/p>
如果你是W一ơ调查,跟着下面q些步骤你能更有效地使用Method List?/p>
1. 选中你的snapshotQ打开"Method List"?img height="36" alt="" src="file:///E:/资料/HTML/jprobe%20使用%20-%20gaojsh69326的专?20-%20CSDNBlog.files/sp7-2-6.gif" width="39" /> 2. "Filter"区域只用于显C在你包中或在你感兴的cM的方法?/p>
3. 点击"Method Time"列名Q把你最消耗时间的Ҏ排在最前面。仔l查看前十个。是不是有一些度量go你惊?你能改进你方法中的算法吗? 4. 点击"Cumulative Time"列名Q把最消耗时间的调用树排在最前面。比较一?Method Time"?Cumulative Time"。虽然方法本w可能效率很高,但也可能调用了低效率的方法,q些低效率的Ҏ可能在你的代码中Q或者在W三方的包或应用框架中?/p>
5. 点击"Number of Calls"列名Q查看一下你哪个Ҏ被调用最多。如果一个或多个度量值同时反映这些方法是低效率的Q需要考虑减少调用q些ҎQ或调用那些效率E好的方法?/p>
Call Graph(见图13)提供一个非常有力的Ҏ调用关系视图。它把J2EE应用攑ֈWebLogic Server上下文环境中Q所以你能看到WebLogic启动的所有线E,包括调用J2EE应用的线E。ؓ了方便查找,Call Graph下面?Method List"?/p>
当分析性能Ӟ在定位J2EE应用的入口点和排除与WebLogicU程有关的数据方面, Call Method是最有效的。在分离出应用的数据基础上,可快速画出执行流E,q用囑Ş清晰地显C出来?/p>
下面是用Call Method的有效技? 1. 选中你的snapshotQ打开"Call Graph" 2. 点击"Find"q且定位你的J2EE应用的入口位|?img height="38" alt="" src="file:///E:/资料/HTML/jprobe%20使用%20-%20gaojsh69326的专?20-%20CSDNBlog.files/sp7-2-8.gif" width="37" />通常是servlet中的doGet()或doPost()Ҏ?/p>
3. 选择Ҏq分d数据形成囑Ş 4. 昄Ҏ的一个子集作为开始,q些Ҏ按照"Cumulative Time"排序是最耗时的方法。当你分析一个方法,在方法的调用树上增加额外的节点?/p>
5. ?Method List"中,Ҏ你发现的瓉位置Q在"Color By"的下拉列表中选择相同度量倹{根据你选择的度量|现在最耗时的方法都以鲜艳的颜色H出昄出来?/p>
6. 选择最耗时的方法。展开父方法树(通过点击节点部分或节点左辚w分的I箭头记?Q就能看到哪个方法调用它了。你可以调用不同的,耗时比较的Ҏ?你需要经常调用这些方法吗? 7. 展开子方法树(指向节点的右?Q可以看到调用了哪个耗时的方法。还有哪些子Ҏ也是耗时的呢?你意识到W三方的Ҏ实际的耗时情况?你能调用一个实C更有效率法的不同方法吗? ?3。JProbe Profiler Call GraphH口 从Method List或Call Graph中,你都能深入地分析Q在一个视图中很方便地看到耗时的方法的度量|q有它们子方法和父方法的度量倹{选择Ҏq打开"Method Detail View" "Method Detail View"(见图14)在窗口的中心昄了选择ҎQ它的父Ҏ在上面,它的子方法在下面。我们对列的头部已经熟悉了,它们和你在其它工具中看到的度量值相同。一个重要的区别是:用于昄父方法和子方法度量DC对所选方法的贡献|不是对它们自q度量倹{所以,如果一个方法被调用?2ơ,q些调用它的ҎQ和12ơ调用分别显C在父方法的图中。如果你想l分析父Ҏ或子ҎQ双击该ҎQ该方法在"Method Detail View"的中心显C?/p>
?4 JProbe Profiler Method DetailH口 要查看你Ҏ中的代码Q选择Ҏq且打开Source Window。你需要指Z的源代码具体位置?/p>
如果你是按行攉数据Q你能在Source Window(见图15)中看到这些数据。在左列中,昄了每条语句的数据度量倹{行U度量值是ҎU度量值的l化Q包括调用次敎ͼ执行该行的时_执行该行时创建的对象数量Q篏U时间和累计对象数量?/p>
提示:如果需要编辑你的代码,q且已经把集成开发环境IDE和JProbe Profiler集成在一起了Q你可以通过选择Edit>Edit Source打开你的集成开发环境。当Ӟ需要运行你重写的代码,q徏立新的JProbe Profiler分析会话Ӟ你做的改变才反映在JProbe Profiler上?/p>
?5 Jprobe Profiler Source Window2.2 使用JProbe Application Server Integration Tool
Integration ID:
JProbe Demo 1
Integration ID Q便于重用每ơ集成过E?
Server Directory:
D:\bea\wlserver6.1
直接输入 WLS 服务器根路径或者通过 " 览 " 方式输入?
Domain Name:
Mydomain
输入你想分析的域名?
Startup Script:
StartWeblogic.cmd
直接输入要调查的服务器的启动脚本或者通过 " 览 " 方式输入?
JProbe Settings: (JPL File)
check the VAR checkbox
集成工具允许你用先前创建的 JPL(JProbe Launchpad) 文g?如果要用由每个工具在启动时默认创徏?JPL 文gQ选择 VAR 复选框?
Java Executable:
d:\sun\jdk1.3.1\bin\Java.exe
可直接输入或通过览方式输入 Java 虚拟机的执行文g路径?
Java Options:
-classic -mx128m -ms64m
有选择地给 Java 虚拟入参数?
3. 识别J2EE应用性能下降
3.1 对象循环QObject CyclingQ?/h3>
3.1.1 启动JProbe Memory Debugger的研I会?/h3>
3.1.2 q行时交?/h3>
3.1.3 分析l果
3.2 性能分析
3.2.1 启动JProbe Profiler调查会话?/h3>
?/p>
Q保存性能信息?/p>
3.2.3 解释l果
3.2.3.1 Time and Object Creation Metrics
3.2.3.2 Method List
3.2.3.3. Call Graph
?/p>
?/p>
?/p>
3.2.3.5 Source Window
本文转自:http://tb.blog.csdn.net/TrackBack.aspx?PostId=599690