JProfiler对应用服务器内存泄漏问题诊断解决方案.docxVIP

2007-04-13/blog/70721利用JProfiler对应用服务器内存泄漏问题诊断一例（转）关键字: java 在中间件应用服务器的整体调优中，有关于等待队列、执行线程，EJB池以及数据库连接池和Statement Cache方面的调优，这些都属于系统参数方面的调优，本文主要从另外一个角度，也就是从应用的角度来解决中间件应用服务器的内存泄露问题，从这个角度来提高系统的稳定性和性能。 项目背景 问题描述 某个大型项目（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%左右，泄漏了大约10%的内存，约300M； 我们在自己搭建的Web应用服务器平台（应用软件版本和生产版本一致）做这一阶段