JVM内存使用超过OS报告的[重复]
我有一个JVM，它报告提交的堆内存约为8GB（其他部分应该在此之上）。但我的操作系统显示内存使用量约为5GB。我理解由于非堆、metaspace等原因，内存使用量可能会超过提交的内存，但是怎么可能使用量比JVM报告的要少呢？
#free -m
total used free shared buff/cache available
Mem: 24115 5536 16355 10 2223 18209
Swap: 0 0 0
本机内存跟踪器(NMT)的输出显示保留内存为~11 GB
#jcmd <pid> VM.native_memory
Total: reserved=12904933KB, committed=11679661KB
- Java Heap (reserved=8388608KB, committed=8388608KB)
(mmap: reserved=8388608KB, committed=8388608KB)
- Class (reserved=1161913KB, committed=127417KB)
(classes #20704)
(malloc=2745KB #33662)
(mmap: reserved=1159168KB, committed=124672KB)
- Thread (reserved=2585224KB, committed=2585224KB)
(thread #2505)
(stack: reserved=2574004KB, committed=2574004KB)
(malloc=8286KB #12532)
(arena=2934KB #5004)
- Code (reserved=264623KB, committed=90231KB)
(malloc=15023KB #22507)
(mmap: reserved=249600KB, committed=75208KB)
- GC (reserved=378096KB, committed=378096KB)
(malloc=34032KB #45794)
(mmap: reserved=344064KB, committed=344064KB)
- Compiler (reserved=776KB, committed=776KB)
(malloc=645KB #1914)
(arena=131KB #7)
- Internal (reserved=53892KB, committed=53892KB)
(malloc=53860KB #67113)
(mmap: reserved=32KB, committed=32KB)
- Symbol (reserved=26569KB, committed=26569KB)
(malloc=22406KB #204673)
(arena=4163KB #1)
- Native Memory Tracking (reserved=6756KB, committed=6756KB)
(malloc=494KB #6248)
(tracking overhead=6262KB)
- Arena Chunk (reserved=11636KB, committed=11636KB)
(malloc=11636KB)
- Tracing (reserved=10456KB, committed=10456KB)
(malloc=10456KB #787)
- Unknown (reserved=16384KB, committed=0KB)
(mmap: reserved=16384KB, committed=0KB)
OS-Debian 9
爪哇-
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)
共有1个答案
为什么JVM报告的提交内存比linux进程驻留集大小更多？这与保留/提交/驻留内存之间的差异有关，如上面的回答所解释的。
结束这个问题。
-
我有一个库伯内特斯豆荚 请求的1500Mb内存 我有2个容器在这个pod内运行，一个是实际应用程序（重型Java应用程序）和一个轻量级日志托运人。 pod始终报告内存使用量为1.9-2Gb。因此，部署是可伸缩的（设置了自动伸缩配置，如果内存消耗，可伸缩POD 黄线表示应用程序内存使用情况 然而，在更深入的调查中，我发现了这一点。 在应用程序容器内的ing上，我运行了命令，它报告了总共或大约16Gb
-
我正在为我的应用程序使用GC选项。 由于大多数人都已经体验过JVM擅长将堆增加到最大堆大小，但它不会将内存释放回操作系统。我遇到了
-
问题内容： 每次从stdin读取字母“ u”时，此代码段将分配2Gb，并且在读取“ a”后将初始化所有分配的字符。 我在具有3Gb内存的linux虚拟机上运行此代码。在使用htop工具监视系统资源使用情况时，我已经意识到malloc操作不会反映在资源上。 例如，当我仅输入一次“ u”（即分配2GB的堆内存）时，我看不到htop中的内存使用量增加2GB。只有当我输入“ a”（即初始化）时，我才会看到
-
我有一个问题，我有一个java应用程序，偶尔会在运行内存溢出后被linux中的oom杀手杀死。我已经监控了堆，它不会增长。事实上，它甚至从来没有通过达到允许的最大值，这是。 因此，我通过启用了本机内存跟踪。然后我运行我的应用程序，取一个基线，然后等到它开始吞噬内存的时候，这时我使用了
-
我在Firebase Cloud Firestore中有8个Firebase用户条目（每个条目中大约有8个简单的字符串字段），还有两个上传的图像，200KB和1.1MB，但Firebase报告的存储空间接近1GB？还有，什么是人工制品？ 看来这个问题是对Firebase存储构件的欺骗 让它开着...
-
我使用Dropwizard指标来衡量应用程序中的各种指标。它们是JVM检测中的几个预定义报告器，但奇怪的是，我找不到任何报告CPU使用情况的报告器。 我可以创建自己的Gauge（使用getThreadCpuTime或类似工具），但我最好的猜测是我错过了一些东西。 我是否在当前的实现中错过了它，或者它比我最初想象的更复杂？