ZGC最大堆大小超过物理内存。

9
JVM选项是什么?
-server -Xmx100g -Xms100g -XX:MaxMetaspaceSize=1G -Xss512k 
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -XX:MaxGCPauseMillis=30 
-XX:ConcGCThreads=4 -XX:ParallelGCThreads=12 
-XX:+DisableExplicitGC -XX:LargePageSizeInBytes=128m
  1. RAM是256G
             total       used       free     shared    buffers     cached
Mem:           251        250          1        100          0        138
-/+ buffers/cache:        112        139
Swap:            7          0          7

  1. top命令显示该进程的RES为303G。
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                           
240731 xxx       20   0 17.0t 302g 297g S  6.6 119.9 256:35.43 java

4. JVM配置文件的显示如下:
./jhsdb jmap --heap --pid 240731
Attaching to process ID 240731, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 11.0.2+9

using thread-local object allocation.
ZGC with 12 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 107374182400 (102400.0MB)
   NewSize                  = 1363144 (1.2999954223632812MB)
   MaxNewSize               = 17592186044415 MB
   OldSize                  = 5452592 (5.1999969482421875MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 1073741824 (1024.0MB)
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
 ZHeap          used 82988M, capacity 1024M, max capacity 27112449862M

还有哪些VM选项可以控制最大容量? ZGC堆是如何工作的?


当前的最大Java堆无法在后备文件系统上获得足够的空间,为什么要使用后备文件系统来容纳当前的最大Java堆?如何更改此选项? - allen
1
这是与ZGC相关的已知“问题”,即虚拟内存实际上。 - Eugene
1个回答

18

由于这个问题经常被问到,而我已经厌倦了解释,让我试着把它写在这里,这样人们可以通过简单搜索获得答案并再次感到快乐(即使只是很短的时间,也是值得的!)。

ZGC 的超额报告主要是由于 ZGC 使用的技术(即多映射)来操作内存页面。由于 ZGC 本质上是 Azul Systems 的 Zing C4 收集器的另一种实现,因此 Zing 也存在相同的“超额报告”RSS 问题。

请查看以下代码:

http://hg.openjdk.java.net/zgc/zgc/file/59c07aef65ac/src/hotspot/os_cpu/linux_x86/zPhysicalMemoryBacking_linux_x86.cpp#l160

void ZPhysicalMemoryBacking::map(ZPhysicalMemory pmem, uintptr_t offset) const {
  if (ZUnmapBadViews) {
    // Only map the good view, for debugging only
    map_view(pmem, ZAddress::good(offset), AlwaysPreTouch);
  } else {
    // Map all views
    map_view(pmem, ZAddress::marked0(offset), AlwaysPreTouch);
    map_view(pmem, ZAddress::marked1(offset), AlwaysPreTouch);
    map_view(pmem, ZAddress::remapped(offset), AlwaysPreTouch);
  }
}

还有这个:

void ZPhysicalMemoryBacking::map_view(ZPhysicalMemory pmem, uintptr_t addr, bool pretouch) const {
  const size_t nsegments = pmem.nsegments();
  // Map segments
  for (size_t i = 0; i < nsegments; i++) {
    const ZPhysicalMemorySegment segment = pmem.segment(i);
    const size_t size = segment.size();
    const void* const res = mmap((void*)addr, size, PROT_READ|PROT_WRITE, MAP_FIXED|MAP_SHARED, _file.fd(), segment.start());
    if (res == MAP_FAILED) {
      ZErrno err;
      map_failed(err);
    }
    // Advise on use of transparent huge pages before touching it
    if (ZLargePages::is_transparent()) {
      advise_view(addr, size);
    }
    // NUMA interleave memory before touching it
    ZNUMA::memory_interleave(addr, size);
    if (pretouch) {
      pretouch_view(addr, size);
    }
    addr += size;
  }
}

映射所有视图:

  • map_view(pmem, ZAddress::marked0(offset), AlwaysPreTouch);
  • map_view(pmem, ZAddress::marked1(offset), AlwaysPreTouch);
  • map_view(pmem, ZAddress::remapped(offset), AlwaysPreTouch);

这意味着对于同一地址,ZGC将其映射到3个不同的视图:marked0、marked1和remapped, 这三个视图在虚拟内存地址中反映出来。这意味着,将有3个不同的虚拟内存地址映射到相同的基础物理内存中,因此每个物理内存页面都有3个虚拟页面映射到它。

如果ZGC成为一个分代GC(即年轻代和老年代,而不是现在的单一代),我们可以预计这个数字将增加到6倍的xmx堆大小。

这就是为什么Azul Zing和Oracle ZGC使用的多映射技术会让人们在“top”命令中感到恐慌的原因。但请注意,报告的仅是虚拟内存空间,所以除非你的系统工具遇到这个混乱的部分,否则没有必要打电话给911。


17
不仅人类感到恐慌,Linux 的 OOM killer 也是如此。您认为我们应该如何处理这个问题? - Arboreal Shark
用于监控:在较新的内核中,您可以直接检查/proc/PID/smaps_rollup文件: Rss: 640096 kB Pss: 463041 kB ... 第二行应该是任何进程实际内存消耗的良好估计。为了防止OOM Killer杀死这类进程:https://unix.stackexchange.com/questions/153585/how-does-the-oom-killer-decide-which-process-to-kill-first这个问题已经过去了3年,关于OOM Killer的新查询已经没有了,所以我认为OOM Killer实际上足够聪明,不会杀死这类进程。 - undefined

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接