0

我有一个 weblogic 服务器，它在启动时会引发 OOM 错误。因此，我的应用程序无法正常运行。

我收集了堆转储[下面的快照]，但是，我不擅长理解输出。

图片快照：http://img51.imageshack.us/img51/7470/heapanalysis.jpg

您能否帮助理解我为什么会收到 OOM 错误？以下是 JVM 参数。

 Starting WLS with line:
 /java -server   -Xms1536m -Xmx1536m -XX:PermSize=512m -XX:MaxPermSize=512m -XX:NewSize=512m -XX:MaxNewSize=512m -XX:SurvivorRatio=6 -Xnoclassgc -XX:+DisableExplicitGC -verbose:gc -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSIncrementalMode -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError

以下是在日志中看到的错误。

> java.lang.OutOfMemoryError: Java heap space Dumping heap to
> java_pid16660.hprof ...
> 115.814: [GC [1 CMS-initial-mark: 743854K(1048576K)] 743854K(1507328K), 0.0050472 secs]
> 115.819: [CMS-concurrent-mark-start] Heap dump file created [778142756 bytes in 3.935 secs] <Jan 20, 2013 10:56:05 PM PST> <Critical>
> <WorkManager> <BEA-002911> <WorkManager weblogic.kernel.System failed
> to schedule a request due to java.lang.OutOfMemoryError: Java heap 
> space java.lang.OutOfMemoryError: Java heap space
> > <Jan 20, 2013 10:56:05 PM PST> <Critical> <WorkManager> <BEA-002911> <WorkManager weblogic.kernel.System failed to schedule a request due
> to java.lang.ArrayIndexOutOfBoundsExcept ion: 26214404
> java.lang.ArrayIndexOutOfBoundsException: 26214404
>         at weblogic.work.CalendarQueue.add(CalendarQueue.java:39)
>         at weblogic.work.RequestManager.addToPriorityQueue(RequestManager.java:263)
>         at weblogic.work.RequestManager.executeIt(RequestManager.java:235)
>         at weblogic.work.ServerWorkManagerImpl.schedule(ServerWorkManagerImpl.java:142)
>         at weblogic.corba.cos.transactions.RecoveryRegistrar.run(RecoveryRegistrar.java:47)
>         Truncated. see log file for complete stacktrace
4

2 回答 2

0

我建议您下载Visual VM，安装所有插件，然后在运行 WebLogic 时将其附加到 PID。

您的 HPROF 很难阅读，但如果这些是字节，我在这里看不到问题。

于 2013-01-21T12:33:38.060 回答
0

由于对 Eclipse Memory Analyzer 工具比较熟悉，所以我将回答如何通过 Eclipse MAT 工具分析 HPROF 文件。

在 Eclipse 中打开 HPROF 文件并完成解析后，如果原因更简单或更明显（对于 MAT），它将指向“泄漏嫌疑人报告”中的罪魁祸首线程/网络请求。

如果您不那么幸运，请执行以下操作：

  1. 单击直方图选项
  2. 根据右侧的 Retained Heap 字段对表进行排序
  3. 直方图视图显示了一个消耗内存的活动对象表，通常是低级
    类，如 HashMaps、Lists 等。
  4. 您的目标是从这些顶级消费者的树中找到类，直到您认为是应用程序代码的一部分的类，
    以及内存消耗的发起者。如果它是一个网络应用程序，您可能会到达启动它的特定用户 HTTP 请求。
  5. 选择最上面的 Class Name 并右键单击选择“Shortest Path to GC Roots -> exclude phantom, soft, weak references”。
  6. 结果表列出了启动负责内存中断的线程的顶级 Java 类或 Http 请求。此列表为您提供了更窄的字段，您可以从中分析导致其行为不端的原因。

注意： MAT 本身就占用大量内存，因此要解析大小为 b/w 5-8 GB 的 HPROF 文件，您至少需要 8 GB RAM 并通过文件设置 MAT 工具的初始化参数：MemoryAnalyzer.ini 特别是 Xmx 参数，对 -Xmx6144m 说

于 2014-09-03T15:10:51.763 回答