Docker由于内存不足（OOM）而停止了Java容器，但JMX监控统计中并未显示出高内存使用情况。

Question

我们遇到了一个状况，在AWS ECS上运行着一个基于Java 11的应用程序的Docker容器。该服务配置为当使用超过1.5GB RAM时被终止。

服务的内存配置如下：

{
  "memory": 1500,
  "memoryReservation": 1137
}

但是，我们在监控仪表板上并未观察到与之相应的内存使用增加。仪表板显示的数据平直（如图所示），这是因为Prometheus不再接收到指标数据。

我们已经尽力限制Java在堆内和堆外的内存使用量。通过Java Native Memory Tracking (NMT)检查后，确认其最大预留使用量约为1.1GB。当前的启动命令如下：

java -Xmx600m -XX:+UseG1GC -XX:MaxMetaspaceSize=220m
-XX:+PrintFlagsFinal -XX:NewRatio=1 -XX:MaxDirectMemorySize=40m
-XX:+PrintFlagsFinal -Xss512k -XX:ProfiledCodeHeapSize=70M
-XX:NonProfiledCodeHeapSize=50M -XX:NonNMethodCodeHeapSize=8M
-XX:+UseCodeCacheFlushing -XX:CompressedClassSpaceSize=32M
-XX:ReservedCodeCacheSize=128M -XX:+SegmentedCodeCache
-javaagent:/opentelemetry-javaagent.jar
-Dotel.javaagent.extensions=/opentelemetry-java-ecs-extension-all.jar
-Dotel.resource.attributes=xxx,aws.ecs.launchtype=ec2
-Dspring.profiles.active=prd-ecs -Dspring.cloud.consul.host=172.17.42.1
-Dspring.cloud.consul.config.watch.enabled=false
-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dlog4j2.formatMsgNoLookups=true -Dserver.port=8080
-Daws.paramstore.enabled=true -Daws.paramstore.region=eu-west-1
-Dspring.main.banner-mode=off -jar /1234-service.jar

我们对为何容器突然使用了额外的400MB内存而JMX指标中却没有任何迹象感到困惑。

//编辑：最老运行容器的NMT输出显示：
总保留=1180115KB，已提交=700171KB，包括Java堆、类、线程、代码、GC、编译器、内部、其他、符号、原生内存跟踪、Arena Chunk、日志、参数、模块、同步器和安全点等各项的详细分配情况。

//编辑2：我们使用的Docker镜像配置如下：
基于amazoncorretto:11镜像，安装了必要的工具，下载并配置了OpenTelemetry Java Agent以及ECS扩展，并设置了用户及Java安全设置。

//编辑3：补充说明，我们还设置了环境变量MALLOC_ARENA_MAX为4以控制内存分配。

尽管我们进行了详尽的内存管理和限制措施，仍然无法解释为何容器内存占用会超出预期且未在监控中体现。

Ned Deily · Answer

Java 在管理内存资源上限方面并不十分高效。Java诞生于个人电脑时代，当时系统拥有RAM和交换空间（SWAP），因此调整参数主要是为了让程序尽可能良好地运行。

随着Docker的出现，Java应用面临了一个新问题：不再有额外的交换空间可用，并且Java能看到的可用内存（主机内存）与Docker为其设定的内存限制并不一致。

例如，你的Java应用可能报告使用了1.1GB的RAM，但即便你在任务定义中分配了1.5GB的RAM，这并不是Java能直接识别的限制。如果你能SSH进入容器，你会发现它报告的内存使用量实际上是宿主机实例的总量。假设你有一个t4g.small实例，拥有2个CPU和2GB RAM来运行这个任务，这意味着Java将看到这些限制，并且某些组件可能会基于此限制进行计算。在此基础上，你还需考虑操作系统、网络、根进程、内部日志等其他进程占用的内存。

你的CloudWatch监控面板实际上展示了所有这些组件的整体实际使用情况，而你的Java监控面板仅报告了它所监控的部分组件的使用情况。因此，你无法了解其他因素正在消耗多少内存。

注意：此外，请记住，本机内存跟踪（Native Memory Tracking）并不能看到所有与Java相关的内存使用情况。它有助于理解内存主要被如何使用，从而帮助优化设置，但它只是一个接近实际情况的估算，而非真实消耗。

建议：在容器环境中运行Java应用时，最好预留更多空间以便开始收集历史数据。比如，先分配8GB运行一个月，观察应用的行为并据此进行优化。然后，根据历史数据来确定内存限制应该设在哪里。不要一开始就设定一个小的限制，然后再试图让Java应用适应这种限制。

Bojangles · Answer

我们也曾遇到过容器中Java应用导致的内存溢出（OOM）问题。
在尝试设置了许多参数后，我们偶然发现了阿里巴巴的推荐指南（https://www.alibabacloud.com/help/en/sae/use-cases/best-practices-for-jvm-heap-size-configuration），其中建议使用以下JVM参数来配置堆大小：

-XX:InitialRAMPercentage=70.0 -XX:MaxRAMPercentage=70.0

通过这些设置，我们成功地将JVM的最大使用内存限制在了可用内存的70%。有些容器即使设置为80%也能运行得相当好，但这要求垃圾回收器的压力要小得多。因此，我们将容器的默认设置调整为70%，这也同时设置了初始RAM和最大RAM的使用比例为70%。这样的配置帮助我们在避免内存溢出问题的同时，也确保了应用有足够的内存空间来平稳运行。

Code Different · Answer

您是否尝试过使用 -Xmx1492M 作为传递给 Java 的参数之一来启动应用？我同样赞同 S.Spieker 提出的建议，即使用初始和最大内存百分比设置，参数为 -XX:InitialRAMPercentage=70.0 -XX:MaxRAMPercentage=70.0。之前有一个非常相似的问题，其中有关于Java在Docker容器中运行的内存管理的更深入解释，您可以在这里找到：Java在Docker容器中的居民集大小(RSS)与Java总承诺内存(NMT)之间的区别。