Swisscom Cloud 上的 Java 应用程序因 OOM 失败

Question

我们有可部署在 Swisscom Cloud 上的 Java 应用程序。具有 1.5 G RAM 的实例。我们正在使用 CF 的下一个参数来限制此应用程序的内存使用。

[jre: { version: 1.8.0_+ }, memory_calculator: {memory_sizes: {stack: 228k}, 
memory_heuristics: {heap: 50, metaspace: 20, native: 50, stack: 10}}]

在实例下，执行ps -ef | 时grep java 我们得到:

-Xms611500K -XX:MetaspaceSize=244600K -Xmx611500K -XX:MaxMetaspaceSize=244600K -Xss228
-XX:MaxDirectMemorySize=256m -XX:InitialCodeCacheSize=32m -XX:ReservedCodeCacheSize=64m 
-XX:CompressedClassSpaceSize=250m -XX:+UseCompressedOops -XX:+UseCompressedClassPointer

不幸的是，一段时间后我们的应用程序进程被终止(“退出状态为 137”)。我们尝试了 CF 的其他不同设置，但没有成功。尽管我们限制了使用的内存，但我们总是会用完 1.5 Gigs 的 RAM。

    2016-11-10T14:31:08.34+0200 [API/0]      OUT App instance exited with guid 
72a197e9-e222-43b5-9828-9553c1d58315 payload: {"instance"=>"", "index"=>0, 
"reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2 error(s) 
occurred:\n\n* Exited with status 137 (out of memory)\n* cancelled\n* cancelled", 
"crash_count"=>1, "crash_timestamp"=>1478781068233690142, 
"version"=>"ebfced51-9973-434b-8ec0-79a8caa86b3b"}

在崩溃之前，我们使用 New Relic 分析堆内存使用情况，您可以在下面看到我们的发现:

这里，大约 4:30 发生了退出，状态为 137(内存不足)。正如您所看到的，内 stub 本没有超出。

当我在崩溃之前在 cf 实例下执行 top 命令时，我得到了下一个:

7 vcap 10 -10 6160764 1.357g 22528 S 27.3 7.4 3:09.52 java

实际上可能有什么问题？因为我看到java进程实际上使用了将近1.4G的RAM，但是从New Relic图表来看并没有使用这么大的内存量。

Answer 1

我假设您的应用程序正在崩溃，因为 CF 容器认为它使用了太多内存。可以通过查看“cf events”中的崩溃事件并确保它们是 OOM 崩溃来验证此假设。假设是容器导致应用程序崩溃，这就是我通常调整这种情况的方式。

java_buildpack 非常努力地控制应用程序的内存使用。然而，似乎仍然有一些应用程序的 jvm 找到了在配置选项之外分配内存的方法。

当我遇到这个问题时，调整配置的最简单方法就是继续增加“ native ”内存比率并减少堆，直到应用程序稳定下来。 Native 是 jvm 可能分配但 buildpack 无法管理的所有内容的包罗万象的存储桶。

我还会删除“heap:600m”配置，因为这只会使启发式计算更加复杂，并可能使增加 native 百分比无效。