原文链接:https://mp.weixin.qq.com/s/HxT-DXNWkPCyDB6qAgKmXA
我最近花了很多时间在 JVM 的内存预留代码上。它开始是因为我们得到了外部贡献,以支持在 Linux 上使用多个大小的 large page。为了以一种好的方式做到这一点,必须首先重构一些其他的东西。在沿着 内存通道 进行这次旅行时,我意识到对 JVM 使用的 large pages 做一个简短的总结可能是一篇非常有趣的文章。
在我们开始讨论 JVM 如何使用它们之前,让我们先简要介绍一下什么是 large pages(大页)。
Large pages 或者叫 huge pages, 是一种减少处理器 TLB 缓存压力的技术。这些缓存用于加快将虚拟地址转换为物理内存地址的时间。大多数体系结构支持多种 page 大小,通常基页大小为 4 KB。对于使用大量内存的应用程序,例如大型 Java 堆,使用更大的 page 粒度映射内存以增加 TLB 中的命中率是有意义的。在 x86-64 上,2 MB 和 1 GB page 可用于此目的,对于内存密集型工作负载,这可能会产生非常大的影响。
Large pages Enabled
在上图中,我们可以看到在使用和不使用大页面时运行几个 SPECjbb 1基准测试的差异。配置上的唯一区别是高性能 JVM 启用了 large pages。结果非常令人印象深刻,对于许多 Java 工作负载来说,启用 large pages 是一个巨大的胜利。
为 Java 启用 large pages 的通用开关是-XX:+UseLargePages,但要利用 large pages,还需要正确配置操作系统。让我们看看如何在 Linux 和 Windows 中配置。
在 Linux 上,JVM 可以通过两种不同的方式使用 large pages:Transparent Huge Pages 和 HugeTLB pages。它们在配置方式上有所不同,但在性能特征上也略有不同。
Transparent Huge Pages,简称 THP,是一种在 Linux 中简化 large pages 使用和启用的方法。启用后,Linux 内核将尝试使用 large pages 来保留足够大且有资格使用 THP。可以在三个不同级别配置 THP 支持:
配置存储在 /sys/kernel/mm/transparent_hugepage/enabled 可以像这样轻松更改:
$ echo "madvise" > /sys/kernel/mm/transparent_hugepage/enabled
JVM 支持在 madvise mode 中配置时使用 THP ,但需要使用 -XX:+UseTransparentHugePages。完成此操作后,Java 堆以及其他内部 JVM 数据结构将由 transparent huge pages 支持。
为了使内核能够满足使用 transparent huge pages 的请求,需要有足够的连续物理内存可用。如果没有内核将尝试对内存进行碎片整理以满足请求。碎片整理可以通过几种不同的方式进行配置,当前策略存储在/sys/kernel/mm/transparent_hugepage/defrag. 有关此配置和其他配置的更多详细信息,请参阅 kernel 内核文档。
这种类型的 large pages 由操作系统预先分配并消耗用于支持它们的物理内存。应用程序可以使用mmap()标志从这个池中保留 page MAP_HUGETLB。这是在 Linux 上为 JVM 使用 large pages 的默认方式,可以通过设置-XX:+UseLargePages或特定标记启用-XX:+UseHugeTLBFS。
当 JVM 使用这种类型的 large pages 时,它会在前面提交由 large pages 支持的整个内存范围。这是确保没有其他预留耗尽操作系统分配的 large pages 池所必需的。这也意味着需要预先分配足够的 large pages 以在保留时支持整个内存范围,否则 JVM 将回退到使用正常 page。
要配置这种类型的 large pages,首先检查可用的 page 大小:
$ ls /sys/kernel/mm/hugepages/hugepages-1048576kB hugepages-2048kB
然后根据你的需求配置 page 大小,如下所示:
$ echo 2500 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
这会尝试分配 2500 个 2 MB 的 pages。应该始终读取实际存储在 nr_hugepages 中的值,以确保内核能够分配请求的数量。
默认情况下,JVM 将在尝试保留 large pages 时使用系统环境默认 large page 大小,你可以通过下面的方式查看系统默认的 large page 大小:
$ cat /proc/meminfo | grep HugepagesizeHugepagesize: 2048 kB
如果你想使用不同的 large page 大小,可以通过设置 JVM LargePageSizeInBytes 标记来完成 。例如:使用 1 GB 的页面-XX:LargePageSizeInBytes=1g。
更多关于 HugeTLB pages 的信息也可以查看 kernel 内核文档。
两种方法各有利弊,选择哪一种取决于多个方面。THP 更易于设置和使用,但在使用 HugeTLB 页面时你有更多控制权。如果延迟是你最关心的问题,那么你可能应该使用 HugeTLB 页面,因为你永远不会等待操作系统释放足够的连续内存。作为替代方案,你可以将 defrag THP 选项配置为在没有 large pages 可用时不停止,但这可能会带来吞吐量成本。如果内存占用是一个问题,THP 是避免必须预先提交整个 Java 堆得更好选择。
使用哪种类型的 large pages 取决于应用程序和环境,但在很多情况下,使用任何类型的 large pages 都会对性能产生积极影响。
在 Windows 上,配置步骤要容易一些,至少在较新的版本上是这样。运行要使用 large pages 的进程的用户需要具有 锁定内存页 权限。在 Windows 10 上,这是通过以下方式完成的:
一旦授予此权限,JVM 将能够使用 large pages(如果使用-XX:+UseLargePages. Windows 上的 JVM large pages 实现与 Linux 上 HugeTLB pages 非常相似。由 large pages 支持的整个预留是预先提交的,以确保我们以后不会出现任何故障。
直到最近,有一个 bug 阻止 G1(默认 GC)在 Windows 上为大于 4 GB 的堆使用 large pages。现在已修复此问题,并且继续使用G1运行大型Minecraft 服务器应该能够通过启用 large pages ** 获得不错的提升**。
一旦你的环境配置正确并且你已经在运行时启用 Java large pages,最好验证 JVM 是否真的使用了 large pages。你可以使用你最喜欢的操作系统工具来检查这一点,但 JVM 也有一些日志记录选项可以帮助解决这个问题。要查看一些基本的 GC 配置,你可以使用-Xlog:gc+init。使用 G1 你可以看到以下输出:
> jdk-16/bin/java -Xlog:gc+init -XX:+UseLargePages -Xmx4g -version[0.029s][info][gc,init] Version: 16+36-2231 (release)[0.029s][info][gc,init] CPUs: 40 total, 40 available[0.029s][info][gc,init] Memory: 64040M[0.029s][info][gc,init] Large Page Support: Enabled (Explicit)[0.029s][info][gc,init] NUMA Support: Disabled[0.029s][info][gc,init] Compressed Oops: Enabled (Zero based)[0.029s][info][gc,init] Heap Region Size: 2M[0.029s][info][gc,init] Heap Min Capacity: 8M[0.029s][info][gc,init] Heap Initial Capacity: 1002M[0.029s][info][gc,init] Heap Max Capacity: 4G[0.029s][info][gc,init] Pre-touch: Disabled[0.029s][info][gc,init] Parallel Workers: 28[0.029s][info][gc,init] Concurrent Workers: 7[0.029s][info][gc,init] Concurrent Refinement Workers: 28[0.029s][info][gc,init] Periodic GC: Disabled
这是在 Linux 上运行的,我们可以看到启用了 Large Page 支持。Explicit 意味着使用了 HugeTLB 页面。如果使用-XX:+UseTransparentHugePages日志行运行将如下所示:
[0.030s][info][gc,init] Large Page Support: Enabled (Transparent)
以上仅显示是否启用了 large pages,如果你想了解有关使用 large pages JVM 的更多详细信息,你可以启用-Xlog:pagesize并获得如下输出:
[0.002s][info][pagesize] CodeHeap 'non-nmethods': min=2496K max=8M base=0x00007fed3d600000 page_size=4K size=8M[0.002s][info][pagesize] CodeHeap 'profiled nmethods': min=2496K max=116M base=0x00007fed3de00000 page_size=4K size=116M[0.002s][info][pagesize] CodeHeap 'non-profiled nmethods': min=2496K max=116M base=0x00007fed45200000 page_size=4K size=116M[0.026s][info][pagesize] Heap: min=8M max=4G base=0x0000000700000000 page_size=2M size=4G[0.026s][info][pagesize] Block Offset Table: req_size=8M base=0x00007fed3c000000 page_size=2M alignment=2M size=8M[0.026s][info][pagesize] Card Table: req_size=8M base=0x00007fed3b800000 page_size=2M alignment=2M size=8M[0.026s][info][pagesize] Card Counts Table: req_size=8M base=0x00007fed3b000000 page_size=2M alignment=2M size=8M[0.026s][info][pagesize] Prev Bitmap: req_size=64M base=0x00007fed37000000 page_size=2M alignment=2M size=64M[0.026s][info][pagesize] Next Bitmap: req_size=64M base=0x00007fed33000000 page_size=2M alignment=2M size=64M
这是非常详细的信息,它是验证 JVM 的哪些部分由 large pages 支持的好方法。上面的输出是使用 JDK 16 生成的,它有一个 bug 导致 CodeHeap 页面大小不正确,它们也由 large pages 支持。