基础架构: 一台WEB服务器(LINUX AS4 MEM4G) , 两台应用服务器LINUX AS4 MEM4G, 一台数据库AIX5L MEM 16G
应用环境: WEB服务器(IHS 2.0) ,每个应用服务器上有两个Websphere 5.1 ND (IBM JAVA 1.4.2),应用实例(JVM 初始256M 最大1280M),数据库Oracle 10g。
环境现状: 由于种种需要其中一台服务器上两个实例停止,现只有一台APP服务器(两个Websphere实例在运行)。
问题描述: 应用已经运行有2年时间,先前偶尔有出现JVM OOM现象,但是最近平凡发生。
           宕机前一分钟空余内存有70%,但是内存消耗非常快,直至内存溢出,CPU达到100%,当时GC全力回收垃圾,但最终还是出现无法恢复现象。会产生4,5
          DUMP  文件。
初步分析: 通过Tivoli 监控JVM内存消耗比较快,但是多数情况能回收到1G内存左右,程锯齿状,我判断程序中没有出现内存泄漏现象。
           查看DUMP文件分析,发现有部分类占用比较大 java/util/Vector 等地方。但是这是程序正常调用。
           通过查看nativestderr,发现有多次申请10M内存失败,AF和GC操作很频繁,可能存在大对象。
           查看Websphere日志,有出现内存溢出报告,其他没有发现什么异常,访问的业务也是正常业务。
初步结论: 可能存在大对象,造成内存碎片,使GC回收资源消耗过大,当业务繁忙时容易造成OOM现象。      问题: 1.客户认为应用代码中有问题,但是查看代码暂无发现。
       2.如何知道大对象是否是应用还是JVM本身的产生的问题?
       3.想知道IBM JDK 1.4.2是否有此类问题,如果解决?
       4.如果当JVM内存还有70%,再出现AF是否正常?请各位高手发表看法,谢谢!
           

解决方案 »

  1.   

    用heapdump分析工具,分析溢出时的heapdump文件。
    此外注意,不要把webspher的最大内存和初始内存设的一样,很容易出问题的。
      

  2.   

    从你的问题描述来看,应该不是内存泄漏的问题,我觉得还是大对象操作上有问题,也就是某个地方程序写的太粗糙了,比如存在大量的String类型对象的操作,比如调用某个方法时传递了一个String类型的对象,但是这个String又很大的情况下,导致String对象Copy过于频繁,内存消耗很快,GC又来不及回收,最终导致OOM
      

  3.   

    谢谢各位帮忙,关于 numen_wlm 所说的String大对象,不知道是不是指接受的是数据库结果集吗?
    我想我们程序里不会有这种情况,我们数据是由HASHMAP封装的,从DUMP信息看到/java/util/verder 泄漏。但是也是我们正常数据封装的。
    由于代码在其他项目中运行正常。现在建议升级JDK 版本和提高JVM最大内存再看看了。