Swisscom Cloud上的Java App因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 GAG的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发生了Exited with status 137 (out of memory)。如你所见，根本没有超出内存。

当我在下一次崩溃之前在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找到在已配置选项之外分配内存的方法的应用程序。

当我遇到这个问题时，我调整配置的最简单方法是简单地继续增加“本机”内存比率并减少堆，直到应用程序稳定为止。对于jvm可能分配的buildpack不管理的任何东西，Native都可以​​捕获所有存储桶。

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