OOM的随机性挂起问题

回复 3# liyuheng


    DUMP可以用MDD4J,Core用TMDA收起

B：解决步骤：

   1、从你的描述有以下信息采集：
      《1》、两次重启WAS后恢复正常
      《2》、一次重启wAS后故障仍在，重启数据库后正常。
      《3》、后台日志出现内存溢出、栈溢出以及本机内存耗尽现象。因此我们可以推断出以下猜测：
     （1）、应用内存问题 （2）数据库问题。

   2、对于OOM问题，首先明确是那种类型的内存溢出呢？Java内存一般主要发生在以下3部分：（1）操作系统本身（2）Java内存区（Heap堆区、permanent区）（3）本地内存区（JVM进程内存、引用的第三方本地代码）。因此，通过工具分析HeapDump、JavaCore文件，定位问题发生源，即“是哪个类或者方法”导致内存问题。
  
   3、至于如何优化，可通过适当调节JVM参数、配置参数、OS参数以及应用程序本身，这部分内容论坛前期活动中有介绍，请关注。

   4、对于db2，通过db2pd分析下数据库当前状态，主要关注缓冲池、排序堆及锁列表等，当然也可以通过其他方式进行。此处“而小机经调整配置后尚有20多G空闲内存，CPU利用率也在10%以内。”描述不是特别清晰，指App Server还是DB Server？

   在整个应用体系架构中，性能问题并非独立存在的，可能会相互依存，因此，在处理性能问题，首先从整体角度出发、层层解析。收起

肯定是隐式内存泄漏，建议关掉PMI，自己截DUMP和CORE文件分析分析收起

针对c:

      当然，能有效解决问题，采取什么思路都可以的，在环境允许的条件下。但从成本角度考虑，一般还是从应用程序角度进行优化是首要选择。收起

回复 6# guansnow


    这2款工具也挺经典的、很不错的收起

A：分析思路：

   1、看现象：主要是Error日志，例如SystemErr.log、db2diag.log。通过错误日志确定是那些应用或者事物导致的，当然，也可以采集系统资源使用情况（CPU、内存、IO及其他）。
   2、抓日志：一般主要是HeapDump、Javacore这2个日志，当然，依据不同问题现象，可能需要获取VerboseGC相关日志。
   3、分析：一般情况下，对于HeapDump可以通过haxxx.jar可以分析；JavaCore可通过jcaxxx.jar进行分析以及VerboseGC可通过gaxxx.jar或者GCLogViewer、MAT等工具查看分析。当然，如有必要进行验证，也可通过其他工具例如：Jprofiler工具进行性能分析，定位可疑的对象。对于DB2数据库，可通过db2top、db2pd命令去分析，到底是因为锁、排序或者参数设置不合理引起。
   4、优化：通过分析结果，进行相关参数调整、应用程序修改。
   5、验证：对修改后的应用进行测试、通过部署相关监控工具或命令，追踪系统运行状况。收起

回复 2# guansnow

自己通过什么工具能对dump和core文件进行比较直观的分析呢收起