Springboot 应用程序在 Cloud Foundry 上崩溃而没有任何崩溃日志

Question

我有一个 spring 启动应用程序在云代工厂上崩溃，没有明显的崩溃日志。 该应用程序有 3 个实例，并且这三个实例中的任何一个都会崩溃，有时一天会崩溃两次，有时会在两天内崩溃一次。 崩溃没有定义的模式。

我尝试添加以下 java 参数，其结果如前所述： -XX:ErrorFile: No file got created on error -XX:+HeapDumpOnOutOfMemoryError: Heap Dump is created when the instance crashs.

当实例崩溃但没有 OOM 日志时会创建堆转储。

I also tried adding embedded tomcat logs for spring boot application with the following packages added: org.apache.tomcat, org.apache.catalina, org.apache.coyote. 尝试在 docker 本地创建 OOM，并且可以看到 OOM 日志出现在应用程序的 tomcat 日志中。

澄清一下，问题是如何找到 memory 的哪个组件负责 OOM？

Answer 1

默认情况下，堆转储是在 VM 工作目录中名为 java_pidpid.hprof 的文件中创建的。 您可以使用 -XX:HeapDumpPath= 选项指定替代文件名或目录。 See https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/clopts001.html for Java hot stop settings

Answer 2

当您在 Cloud Foundry 上运行 Java 应用程序时，使用-XX:+HeapDumpOnOutOfMemoryError不会有帮助。 添加该选项会触发堆转储，但它将被写入您的应用程序容器中。 一旦完成，容器将转到 go ，您将无法获取写入的文件。

为了在 Cloud Foundry 上进行这项工作，Java buildpack 提供了一些帮助。

1. Java buildpack 配置了一个添加到 JVM 的 killagent。 此代理将在出现 OutOfMemoryError 时执行。 它将打印 memory 使用情况的直方图，还将打印 memory 汇总。 您将在cf logs的 output 中看到这些。

   前任：

    Resource exhaustion event: the JVM was unable to allocate memory from the heap. ResourceExhausted; (1/0) | Instance Count | Total Bytes | Class Name | | 18273 | 313157136 | [B | | 47806 | 7648568 | [C | | 14635 | 1287880 | Ljava/lang/reflect/Method; | | 46590 | 1118160 | Ljava/lang/String; | | 8413 | 938504 | Ljava/lang/Class; | | 28573 | 914336 | Ljava/util/concurrent/ConcurrentHashMap$Node; |

   和

    Memory usage: Heap memory: init 65011712, used 332392888, committed 351797248, max 351797248 Non-heap memory: init 2555904, used 63098592, committed 64815104, max 377790464 Memory pool usage: Code Cache: init 2555904, used 14702208, committed 15007744, max 251658240 PS Eden Space: init 16252928, used 84934656, committed 84934656, max 84934656 PS Survivor Space: init 2621440, used 0, committed 19398656, max 19398656 Compressed Class Space: init 0, used 5249512, committed 5505024, max 19214336 Metaspace: init 0, used 43150616, committed 44302336, max 106917888 PS Old Gen: init 43515904, used 247459792, committed 247463936, max 247463936

   所有 Java 应用程序在使用 Cloud Foundry 上的 Java buildpack 运行时都会获得此信息，它有助于了解 memory 在应用程序崩溃时的使用情况。 如果您没有看到这一点，那么您的应用程序由于其他原因而崩溃（见下文）。

2. 如果您需要更深入地了解 memory 的使用情况，您可以获得完整的堆转储。 为此，您需要将持久存储绑定到您的应用程序。 如果您将卷服务绑定到服务名称包含heap-dump的应用程序，则 Java 构建包将设置此存储以自动用于捕获堆转储。

   如果名称或标签中带有字符串 heap-dump 的卷服务绑定到应用程序，则终端堆转储将以<CONTAINER_DIR>/<SPACE_NAME>-<SPACE_ID[0,8]>/<APPLICATION_NAME>-<APPLICATION_ID[0,8]>/<INSTANCE_INDEX>-<TIMESTAMP>-<INSTANCE_ID[0,8]>.hprof模式写入<CONTAINER_DIR>/<SPACE_NAME>-<SPACE_ID[0,8]>/<APPLICATION_NAME>-<APPLICATION_ID[0,8]>/<INSTANCE_INDEX>-<TIMESTAMP>-<INSTANCE_ID[0,8]>.hprof

---

如果您没有看到 JVM killagent 中的 output 或者您没有看到生成到持久存储的堆转储：

1. 检查是否已添加 JVM 代理。 当 buildpack 在暂存期间运行时，您应该会看到下载并安装了 killagent。
2. 它还应该显示在 Java buildpack 生成的启动命令中。 检查启动命令以确保您看到代理。 请注意，如果您使用cf push -c指定自己的启动命令，则 buildpack 将无法添加代理。
3. 您只是没有遇到 OutOfMemoryError。 您的应用程序可能由于其他原因而崩溃。 最常见的是您超出了容器的 memory 限制，而不是 JVM 的 memory 限制。 在这种情况下，容器将立即崩溃，您将无法从 killagent 获得 output。

希望有帮助！