1

我们有可在 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 发生了Exited with status 137 (out of memory)。如您所见，根本没有超出内存。

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

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

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

4

1 回答 1

1

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

java_buildpack 非常努力地包含应用程序的内存使用。但是，似乎仍然有 jvm 找到在配置选项之外分配内存的方法的应用程序。

当我遇到这个问题时，我调整配置的最简单方法是简单地继续增加“本机”内存比率并减少堆，直到应用程序稳定。对于 jvm 可能分配的 buildpack 无法管理的任何内容，Native 都是包罗万象的存储桶。

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

于 2016-11-03T21:58:41.063 回答