利用JProfiler对应用服务器内存泄漏问题诊断一例.docxVIP

参数名称 参数值 参数解释 kernel.default(Thread?Count) 120 执行线程数目，是并发处理能力的重要参数 Session?Timeout 240?分钟（4?小时） HttpSession?会话超时 利用?JProfiler?对应用服务器内存泄漏问题诊断一例 曾胜财? ,?IBM?BCS?部门?I/T?架构师 2005?年?9?月 在中间件应用服务器的整体调优中，有关于等待队列、执行线程，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:+PrintGCDetails?-Xloggc:./inwebapp1/gc.$$ 可以看出目前生产系统中?Web?应用服务器的内存分配为?3G?Memory。 Web?应用服务器的重要部署参数 分析 分析方法 内存长期占用并导致系统不稳定一般有两种可能： 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?应用服务器的内存在高位长期占用的原因了：是内存泄露！ 并且正是由于这个原因导致系统不稳定、响应客户请求越来越慢的。