在Docker容器中运行的JVM的驻留集大小(RSS)和Java总提交内存(NMT)之间的差异

Question

场景：

我有一个在docker容器中运行的JVM。我使用两个工具做了一些内存分析:1)Top2)Java本地内存跟踪。

问题：

1. 给docker容器的总内存=2 GB
2. Java最大堆=1 GB
3. 提交总量(JVM)=始终小于800 MB
4. 使用的堆(JVM)=始终小于200 MB
5. 未使用堆(JVM)=始终小于100 MB。
6. RSS=约1.1GB.

那么，1.1 GB(RSS)和800 MB（Java总提交内存）之间的内存消耗是什么呢？

Answer 1

在Mikhail Krestjaninoff的“分析Docker容器中的java内存使用情况”中可以找到一些线索：

（明确地说，在三年后的2019年5月，使用openJDK 8U212，情况确实有所改善）

驻留集大小是进程当前分配和使用的物理内存量（没有交换出的页）。它包括代码、数据和共享库（在使用它们的每个进程中都被计算在内）

RSS = Heap size + MetaSpace + OffHeap size

docker exec my-app jcmd 1 VM.native_memory summary

不要担心“未知”部分--NMT似乎是一个不成熟的工具，不能处理CMS GC（当您使用另一个GC时，该部分将消失）。

请记住，NMT显示的是“提交”内存，而不是“常驻”内存（您通过ps命令获得）。换句话说，可以提交内存页而不考虑作为驻留页（直到它被直接访问）。

这意味着非堆区域（堆总是预先初始化的）的NMT结果可能大于RSS值。

我正在运行一个简单的Scala(JVM)应用程序，它将大量数据加载到内存中或从内存中取出。
我将JVM设置为8G堆(-xmx8g)。我有一台内存为132G的机器，它不能处理超过7-8个容器，因为它们的增长远远超过了我对JVM施加的8G限制。

(Docker stat以前被报告为误导性的，因为它显然将文件缓存包含在总内存使用信息中）

Docker stat显示每个容器本身使用的内存比JVM应该使用的内存多得多。例如：

CONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/O
dave-1 3.55% 10.61 GB/135.3 GB 7.85% 7.132 MB/959.9 MB
perf-1 3.63% 16.51 GB/135.3 GB 12.21% 30.71 MB/5.115 GB