为什么JVM报告的已提交内存比linux进程驻留集大小更多？

  • Z时代
  • 2024-01-10
  • 分类：问答

在启用了本机内存跟踪的Java应用程序（在YARN中）运行时（-XX:NativeMemoryTracking=detail请参阅https://docs.oracle.com/javase/8/docs/technotes/guides/vm/nmt-8.html和https：//

docs。

oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html），我可以看到JVM在不同类别中使用了多少内存。

我在jdk 1.8.0_45上的应用显示：

Native Memory Tracking:
Total: reserved=4023326KB, committed=2762382KB
- Java Heap (reserved=1331200KB, committed=1331200KB)
(mmap: reserved=1331200KB, committed=1331200KB)
    Class (reserved=1108143KB, committed=64559KB)
    (classes #8621)
    (malloc=6319KB #17371)
    (mmap: reserved=1101824KB, committed=58240KB)
    Thread (reserved=1190668KB, committed=1190668KB)
    (thread #1154)
    (stack: reserved=1185284KB, committed=1185284KB)
    (malloc=3809KB #5771)
    (arena=1575KB #2306)
    Code (reserved=255744KB, committed=38384KB)
    (malloc=6144KB #8858)
    (mmap: reserved=249600KB, committed=32240KB)
    GC (reserved=54995KB, committed=54995KB)
    (malloc=5775KB #217)
    (mmap: reserved=49220KB, committed=49220KB)
    Compiler (reserved=267KB, committed=267KB)
    (malloc=137KB #333)
    (arena=131KB #3)
    Internal (reserved=65106KB, committed=65106KB)
    (malloc=65074KB #29652)
    (mmap: reserved=32KB, committed=32KB)
    Symbol (reserved=13622KB, committed=13622KB)
    (malloc=12016KB #128199)
    (arena=1606KB #1)
    Native Memory Tracking (reserved=3361KB, committed=3361KB)
    (malloc=287KB #3994)
    (tracking overhead=3075KB)
    Arena Chunk (reserved=220KB, committed=220KB)
    (malloc=220KB)

这显示了2.7GB的已承诺内存，包括1.3GB的已分配堆和近1.2GB的已分配线程堆栈（使用许多线程）。

但是，在运行时ps ax -o pid,rss | grep

<mypid>或top它仅显示1.6GB的RES/rss驻留内存。检查交换说没有使用：

free -m

total used free shared buffers cached

Mem: 129180 99348 29831 0 2689 73024

-/+ buffers/cache: 23633 105546

Swap: 15624 0 15624

为什么当仅驻留1.6GB时，JVM会指示已分配2.7GB内存？剩下的去了哪里？

回答：

我开始怀疑堆栈内存（与JVM堆不同）似乎是预先提交的，而没有驻留，并且随着时间的流逝，驻留内存仅达到实际堆栈使用率的最高水位。

是的，除非另有说明，至少在Linux上，mmap是懒惰的。页面仅在写入后才由物理内存支持（由于零页面优化，因此读取不足）

GC堆内存有效地被复制收集器或预调零（-XX:+AlwaysPreTouch）所触及，因此它将始终处于驻留状态。线程堆栈otoh不受此影响。

为了进一步确认，您可以使用pmap -x <java pid>各种地址范围的RSS并将其与NMT虚拟内存映射的输出交叉引用。

保留的内存已与映射PROT_NONE。这意味着虚拟地址空间范围在内核的vma结构中具有条目，因此不会被其他mmap /

malloc调用使用。但是它们仍然会导致页面错误以SIGSEGV的形式转发到进程，即访问它们是一个错误。

这对于使连续的地址范围可供将来使用很重要，这反过来又简化了指针运算。

例如，已提交但未由存储支持的内存已映射- PROT_READ |

PROT_WRITE但访问它仍会导致页面错误。但是，该页面错误由内核静默处理，方法是将其与实际内存一起备份，并像没有任何反应一样返回执行。

也就是说，这是一个实现细节/优化，流程本身不会注意到。

细分概念：

：根据最后一个GC，活动对象占用的内存量

：已使用除PROT_NONE之外的其他内容映射的地址范围。由于延迟分配和分页，它们可能会或可能不会由物理或交换支持。

：已mmap为特定内存池预先映射的总地址范围。

该 预留-致力于 差由PROT_NONE映射，这是保证不被物理存储器被备份

：当前处于物理内存中的页面。这意味着代码，堆栈，已提交的内存池的一部分，以及最近已被访问的mmaped文件的一部分，以及JVM控制范围之外的分配。

：所有虚拟地址映射的总和。涵盖已提交，保留的内存池，还包括映射文件或共享内存。这个数字很少提供信息，因为JVM可以提前保留很大的地址范围或mmap大文件。

以上是 为什么JVM报告的已提交内存比linux进程驻留集大小更多？ 的全部内容， 来源链接： utcz.com/qa/418686.html

回到顶部