总第23篇
2021年 第023篇
Docker 下运行的 Java 应用程序中的内存消耗时遇到了一个有趣的问题。该XMX参数被设置为256M，但Docker监控工具显示几乎两倍多使用的内存
下面我们将尝试了解这种奇怪行为的原因，并找出应用程序实际上消耗了多少内存。
Docker和内存
首先，让我们看一下我用来启动应用程序的 docker 容器参数：
其中当您开始尝试解释docker stats my-app命令的结果时，问题就开始了：
所以，我们只需运行以下命令：
嗯……好奇怪！
PS 说我们的应用程序只消耗375824K / 1024 = 367M。似乎我们的问题多于答案
为什么 docker statsinfo 与ps数据不同？
第一个问题的答案非常简单 - Docker 有一个错误（或一个功能 - 取决于您的心情）：它将文件缓存包含在总内存使用信息中。所以，我们可以避免这个指标并使用ps关于 RSS 的信息，并认为我们的应用程序使用367M，而不是 504M （因为文件缓存可以在内存不足的情况下轻松刷新）。
好吧 -但为什么 RSS 比 Xmx 高？这是一个非常有趣的问题！让我们试着找出来。
有JMX
分析 Java 进程最简单的方法是 JMX（这就是我们在容器中启用它的原因）。
理论上，在java应用程序的情况下
其中 OffHeap 由线程堆栈、直接缓冲区、映射文件（库和 jar）和 JVM 代码本身组成；
根据jvisualvm，承诺的堆大小为136M（而只有67M被“使用”）
MetaSapce 大小为68M（使用了 67M）
换句话说，我们必须解释367M - (136M + 67M) = 164M的 OffHeap 内存。
我的应用程序（平均）有30 个实时线程：
这些线程中的每一个都消耗 1M：
所以，这里我们可以再增加30M。
应用程序使用 DirectBuffer 的唯一地方是 NIO。就我从 JMX 中看到的而言，它不会消耗大量资源 - 只有98K：
但是根据 pmap
加
我们这里只有20M。
在这里，您应该记住，当您使用 Docker（或任何其他虚拟化）时，“共享”库（libc.so、libjvm.so 等）并不是那么共享的——每个容器都有自己的这些库的副本。
因此，我们仍然需要解释164M - (30M + 20M) = 114M
本机内存跟踪
上面的所有操作都暗示我们 JMX 不是我们想要的工具 :)
我已经-XX:NativeMemoryTracking=summary向 JVM添加了属性，因此我们可以从命令行调用它：
有关 JVM 进程内存的所有信息都在您的屏幕上！如果这不明显，您可以在此处找到有关每个点含义的信息。不要担心“未知”部分 - 似乎 NMT 是一个不成熟的工具，无法处理 CMS GC（当您使用另一个 GC 时，此部分会消失）。
请记住，NMT 显示“已提交”的内存，而不是“常驻”（您通过ps命令获得）。换句话说，一个内存页可以在不考虑为常驻者的情况下被提交（直到它被直接访问）。这意味着非堆区域（堆始终预初始化）的 NMT 结果可能大于 RSS 值
总结
结果，尽管我们将 jvm 堆限制设置为256m，但我们的应用程序消耗了367M。“其他” 164M主要用于存储类元数据、编译代码、线程和 GC 数据。
前三点通常是应用程序的常量，因此唯一随堆大小增加的就是 GC 数据。这种依赖性是线性的，但“k”系数 ( y = kx + b) 远小于 1。例如，在我们的应用程序中，对于 380M的已提交堆，GC 使用78M（在当前示例中，我们有140M 对 48M）。
我能说些什么作为结论？嗯……永远不要把“java”和“micro”放在同一个句子中:) 我在开玩笑——请记住，在 java、linux 和 docker 的情况下处理内存比起初看起来要棘手一些。
分享、点赞、在看，给个3连击呗