方案:
我有一个在Docker容器中运行的JVM。我使用两个工具做了一些内存分析:1)top2)Java本机内存跟踪。这些数字看起来很混乱,我正在试图找到导致差异的原因。
问题:
RSS被报告为1272 MB用于Java进程,而总Java内存被报告为790.55 MB。我该如何解释剩余内存1272 - 790.55 = 481.44 MB去了哪里?
为什么在查看了SO上的this question后仍要保留此问题:
我确实看到了答案,并且解释得很有道理。但是,在获得Java NMT和pmap -x的输出后,我仍然无法具体Map哪些Java内存地址是实际驻留的和物理Map的。我需要一些具体的解释(详细的步骤)来找出RSS和Java总提交内存之间的差异的原因。
顶部输出
Java不超过
Docker内存统计数据
图表
我有一个运行了超过48小时的码头集装箱。现在,当我看到一个图表,其中包含:
1.分配给Docker容器的总内存= 2 GB
- Java最大堆= 1 GB
1.提交总量(JVM)=始终小于800 MB
1.已用堆(JVM)=始终小于200 MB
1.未使用的堆(JVM)=始终小于100 MB。 - RSS =约1.1 GB。
那么,是什么在吞噬1.1 GB(RSS)和800 MB(Java总提交内存)之间的内存?
2条答案
按热度按时间1aaf6o9v1#
在Mikhail Krestjaninoff的“Analyzing java memory usage in a Docker container“中,您可以找到一些线索:
(And需要说明的是,三年后的2019年5月,thesituation does improveswith openJDK 8u212)
ResidentSetSize指当前分配给一个处理并由其使用的物理内存数量(不包括换出的页面)。它包括代码、数据和共享库(计算在每个使用它们的处理中)
为什么docker统计信息与ps数据不同?
第一个问题的答案很简单-Docker has a bug (or a feature - depends on your mood):它将文件缓存包括在总内存使用信息中。因此,我们可以避免使用这个指标,而使用有关RSS的
ps
信息。好吧,好吧-但是为什么RSS比Xmx高?
理论上,在java应用程序的情况下
其中OffHeap由线程堆栈、直接缓冲区、Map文件(库和jar)和JVM代码本身组成
自从JDK 1.8.40以来,我们有**Native Memory Tracker**!
正如您所看到的,我已经将
-XX:NativeMemoryTracking=summary
属性添加到JVM中,因此我们可以从命令行调用它:(This是OP所做的)
不要担心“未知”部分-似乎NMT是一个不成熟的工具,不能处理CMS GC(当您使用另一个GC时,该部分消失)。
请记住,NMT显示的是“committed”内存,而不是“resident”内存(通过ps命令获得)。换句话说,可以提交内存页而不将其视为驻留内存(直到直接访问它为止)。
这意味着非堆区域的NMT结果(堆始终是预初始化的)可能大于RSS值。
(that是“Why does a JVM report more committed memory than the linux process resident set size?“的用武之地)
因此,尽管我们将jvm堆限制设置为256 M,但我们的应用程序消耗了367 M。“其他”的164 M主要用于存储类元数据、编译代码、线程和GC数据。
前三个点对于应用程序来说通常是常量,因此唯一随堆大小而增加的是GC数据。
这种依赖性是线性的,但是“
k
“系数(y = kx + b
)远小于1。更一般地说,这似乎是issue 15020的后续问题,它报告了自Docker 1.7以来的类似问题
我正在运行一个简单的Scala(JVM)应用程序,它将大量数据加载到内存中,然后从内存中加载出来。
我将JVM设置为8 G堆(
-Xmx8G
)。我有一台内存为132 G的机器,它不能处理超过7-8个容器,因为它们的增长远远超过了我对JVM施加的8 G限制。(
docker stat
以前被报告为误导性的,因为它显然将文件缓存包括在总内存使用信息中)docker stat
显示每个容器本身使用的内存比JVM应该使用的要多得多。看起来好像JVM正在向操作系统请求内存,而内存是在容器中分配的,并且JVM在其GC运行时释放内存,但容器并没有将内存释放回主操作系统。因此,内存泄漏。
cld4siwp2#
免责声明:我不是Maven
我最近遇到过一个生产事件,在重载下,pod的RSS有一个很大的跳跃,Kubernetes杀死了pod。没有OOM错误异常,但是Linux以最硬的方式停止了这个过程。
RSS和JVM预留的总空间之间有很大的差距。堆内存,本地内存,线程,一切看起来都很好,但是RSS很大。
我们发现,这是由于malloc内部的工作方式。内存中有很大的间隙,malloc会从那里获取内存块。如果你的机器上有很多内核,malloc会尝试适应并给予每个内核自己的空间来获取空闲内存,以避免资源争用。设置
export MALLOC_ARENA_MAX=2
解决了这个问题。你可以在这里找到更多关于这种情况的信息:1.不断增长的Java进程驻留内存使用率(RSS)
另外,我不知道为什么RSS的内存会有一个跳跃。pod是建立在Sping Boot + Kafka之上的。