服务器项目系统响应40秒,利用JProfiler对利用服务器内存泄露问题诊断一例（转）_76044...

关键字: java

在其中件利用服务器的大局调优中，有关于期待队列、厉行线程，EJB池以及数据库连接池和StatementCache方面的调优，这些都属于系统参数方面的调优，本文重要从另外一个角度，也即便从利用的角度来处理其中件利用服务器的内存败露问题，从这个角度来长进系统的安宁性和功能。

项目背景

问题描写

某个大型项目(Use Case用例超过300个)，在项目上线后，其Web利用服务器经常宕机。出现为：

1. 利用服务器内存常年不科学挪借，内存经常处于高位挪借，很难回收到低位；

2. 利用服务器极为不安宁，几乎每两天重新启用顺次，有时甚至每天重新启用顺次；

3. 利用服务器经常做Full GC(Garbage

Collection)，而且工夫很长，大约必需30-40秒，利用服务器在做Full

GC的时候是不响应客户的交易哀求的，极其波及系统功能。

Web利用服务器的物理安排

一台Unix服务器(4CPU，8G

Memory)来安排本Web利用过程；Web利用过程安排在其中件利用服务器上；安排了一个节点(Node)，只搭配一个利用服务器实例(Instance)，未曾做Cluster安排。

Web利用服务器启用脚本中的内存参数

MEM_ARGS="-XX:MaxPermSize=128m -XX:MaxNewSize=512m

-Xms3096m

-Xmx3096m -XX:+Printetails

-Xloggc:./inwebapp1/gc.$$"

能够看浮现在出产系统中Web利用服务器的内存分配为3G Memory。

Web利用服务器的重要安排参数 参数名目 参数值 参数解释 kernel.default(Thread Count) 120

厉行线程数目，是并发处理力气的重要参数 Session Timeout 240分钟(4小时) HttpSession会话超时

分析

分析措施

内存常年挪借并导致系统不安宁等闲有两种可能：

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%左右，400电话泄露了大约10%的内存，约300M；

我们在自己搭建的Web利用服务器平台(利用软件版本和出产版本统一)做这一阶段雷同的查询交易；阐明对统一个黑盒(Web利用)施加同样的刺激(雷同的垄断过程和查询交易)以期重现假象；

我们利用Jprofiler工具对Web利用服务器的内存举行实时监控；

做完这些交易后，用户退出系统，并期待Web利用服务器的HttpSession超时(我们这里设置为15分钟)；

我们对Web利用服务器做了两次迫使性的内存回收垄断。

觉察如下：

图三

如图三所示，内存穿越HttpSession超时后，并迫使gc后，依旧有许多的对象未曾释放。例如：gov.gdlt.taxcore.comm.security.MenuNode，依旧有807个实例未曾释放。

我们继续追溯觉察，这些MenuNode率先储藏在一个ArrayList对象中，然后觉察这个ArrayList对象又是储藏在WHsessionAttrVO对象的Map中，WHsessionAttrVO对象又是储藏在ExternalSessionManager的staic

Map中(名目为sessionMap)，如图四所示。

图四

我们觉察gov.gdlt.taxcore.taxevent.xtgl.comm.WHsessionAttrVO中保留了EJBSessionId消息(登拨取户的单一符号，由用户id+登录工夫戳构成，每天都不同)和一个HashMap，这个HashMap中的内容有http://www.ji9site.info/guanyuwomen/628.html：

ArrayList: 内有MenuTreeNodes(菜单树节点) HashMap: 内有垄断人员代码消息

CurrentVersion:目前版本号 CurrentTime:目前系统工夫

WHsessionAttrVO这个对象的最后储藏在ExternalSessionManager的static

MapsessionMap中，由于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为457K。

我们做如下估价：

假想平衡每天有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及其大约登录消息(大约每个用户的登录消息只有1http://www.meibaby.info/lianxiwomen/612.html.5K左右，而现在这个体系的营业网点用户为1万左右，因而大约只挪借Web服务器15M内存)。

厉行情形

批准的计划：某某软件商批准了新的会话登录消息存贮计划，即:ExternalSessionManager的成员变量sessionMap中不再保留用户菜单消息，只保留大约的登录消息；存储措施批准用户id(11位)作为键值(key)来保留用户大约登录消息。

大约分析：由于大约登录消息只有1K左右，而现在内网登录的用户总数也只有8887个，因而只保留了大约10M-15M的消息在内存，挪借量很小，并且不会有内存泄露。用户菜单消息保留在session中，万一用户退出时点击logout版面，那么利用服务器能够很快地释放这局部内存；万一用户直接关闭窗口，那么保留在session中的菜单消息只有等会话超时后才会由系统打扫并回收内存。

监控情形：

图九

如图九所示，ExternalSessionManager中只保留了容易的登录消息(Map中保留了WHsessionAttrVO对象)，包括：目前版本(currentversion)，垄断人员代码大约消息(czrydmInfo)，目前工夫(currenttime)。

图十

如图十所示，这个登拨取户的大约消息只有1368 bytes，大约1.3K

图十一

如图十一所示，一共同两个用户(雷同的用户id)登录系统，当一个用户利用logout版面退出时，保留在session中的菜单消息(MenuNode)即刻释放了，因而Difference一栏收缩了806个菜单项。

图十二

如图十二所示，当另外一个会话超时后，利用服务器回收了全副会话的菜单消息(MenuNode)，图上曾经未曾MenuNode对象了。并且由于是统一个用户登录，因而保留在ExternalSessionManager成员变量sessionMap中的对象WHsessionAttrVO只有一个(id=24400001129)，而未曾发生多个，未曾因为多次登录而发生多个对象的收获，避免了内存泄露问题的揭示，处理了前期定位的内存泄露问题。

图十三

如图十三所示，穿越gc内存回收后，觉察内存回收比拟安宁，大约都回收到了起码点，也验证了内?**丛苈丁?

结论与提倡：从测验情形看，处理了前期定位的内存泄露问题。

出产系统厉行后的监控与分析

穿越调优后，我们觉察：在2005年6月2日晚9点40左右重新安排、启用了Web利用服务器(批准了新的调优计划)。穿越几天的监控运行，觉察Web利用服务器现在运行大约安宁，现在未曾揭示新的内存泄露问题，下列图示解释了这一点

图十四 2005年6月2日

如图十四所示，6月2日晚21.7(21点42分)重新启用利用服务器，内存挪借很少，大约为15%(请看红色曲线)，每次GC花费的工夫也很短，大约在5秒以内(请看黄色曲线)。

图十五 2005年6月3日周五

如图十五所示，在6月3日周五的全副工作日内，内存的回收大约到位，回收位置扼制在20%-30%之间，也即便在600M-900M之间(请看红色曲线的起码点)，始终能够回收2G的内存供利用过程利用，每次GC的工夫最高不超过20秒，Full

GC平衡在10秒左右，工夫花费比拟短(请看黄色曲线)。

图十六2005年6月5日周日

如图十六所示，在周日休息日其间，Web利用服务器全天只做了大约4次Full

GC(黄色曲线中的小山峰)，工夫都在10秒以内；大的Full GC后，内存只挪借10%，内存回收很彻底。

图十七 2005年6月6日周一

如图十七所示，在周一工作日其间，内存回收还是不错的，大约能够回收到30%(见红色曲线的起码点)，即：挪借900M内存空间，富余2G的内存空间；Full

GC的工夫大局部扼制在20秒以内，平衡15秒(见黄色曲线)。

图十八 2005年6月7日周二

如图十八所示，在6月7日周二早上，大约8:30左右，Web利用服务器作了顺次Full

GC，用了10秒的工夫，把内存回收到了10%的位置，为后续的利用腾出了90%的内存空间。内存回收依旧比拟彻底，解释大约未曾内存泄露问题。

穿越这几天的监控分析，我们能够看出：

Web利用服务器的内存利用曾经比拟科学http://www.b3today.info/guanyuwomen/601.html，内存在工作日的挪借在20%至30%之间，约1G的内存挪借，有2G的内存空间富有；而在安逸工夫(周日，每天的凌晨等)内存能够回收到10%，有90%的内存空间富有；

Web利用服务器的Full GC的次数显明收缩了并且每次Full

GC挪借的工夫也很少，大约扼制在10-20秒之间，有的甚至在10秒以内，显明改进了内网利用服务器内存的利用；

从6月2日重新安排尔后，Web利用服务器未曾揭示宕机重启的假象。

归纳

穿越本文，我们能够看到，内存的败露将会导致服务器的宕机，系统功能就更别说了。对于系统内存败露问题该当从服务器GC日志方面举行早诊断，利用工具早确认并提出处理计划，肃清内存败露问题，长进系统功能，以规避项目危险。

原作者：曾胜财 , IBM BCS 部门

I/T架构师小结一下：C++中有许多混杂的(措施或)知识点其实是留着应付一些混杂问题的。