Java中使用大页面提升性能 - kstefanj


大页面是一种减少处理器TLB缓存压力的技术。这些缓存用于加快将虚拟地址转换为物理内存地址的时间。大多数体系结构支持多种页面大小，通常基页大小为 4 KB。对于使用大量内存的应用程序，例如大型 Java 堆，使用更大的页面粒度映射内存以增加 TLB 中的命中率是有意义的。在 x86-64 上，2 MB 和 1 GB 页面可用于此目的，对于内存密集型工作负载，这可能会产生非常大的影响。JVM启用了大页面获得20%高性能提升。
 
为 Java 启用大页面的通用开关是-XX:+UseLargePages，但要利用大页面，还需要正确配置操作系统。让我们看看 Linux 和 Windows 是如何做到的。
在 Linux 上，JVM 可以通过两种不同的方式使用大页面：透明大页面和HugeTLB 页面。它们在配置方式上有所不同，但在性能特征上也略有不同。

Linux透明大页面
Transparent Huge Pages，简称 THP，是一种在 Linux 中简化大页面使用和启用的方法。启用后，Linux 内核将尝试使用大页面来保留足够大且有资格使用 THP。可以在三个不同级别配置 THP 支持：

  • always - 任何应用程序都会自动使用透明大页面。
  • madvise- 透明大页面仅在应用程序使用madvise()标志MADV_HUGEPAGE来标记某些内存段应由大页面支持时才使用。
  • never - 从不使用透明大页面。

配置存储在/sys/kernel/mm/transparent_hugepage/enabled并且可以像这样轻松更改：
$ echo "madvise" > /sys/kernel/mm/transparent_hugepage/enabled
JVM 支持在madvisemode 中配置时使用 THP ，但需要使用-XX:+UseTransparentHugePages. 完成此操作后，Java 堆以及其他内部 JVM 数据结构将由透明大页面支持。
为了使内核能够满足使用透明大页面的请求，需要有足够的连续物理内存可用。如果没有内核将尝试对内存进行碎片整理以满足请求。碎片整理可以通过几种不同的方式进行配置，当前策略存储在/sys/kernel/mm/transparent_hugepage/defrag. 有关此配置和其他配置的更多详细信息，请参阅内核文档。
 
Linux HugeTLB页面
这种类型的大页面由操作系统预先分配并消耗用于支持它们的物理内存。应用程序可以使用mmap()标志从这个池中保留页面MAP_HUGETLB。这是在 Linux 上为 JVM 使用大页面的默认方式，可以通过设置-XX:+UseLargePages或特定标志启用：-XX:+UseHugeTLBFS。
当 JVM 使用这种类型的大页面时，它会在前面提交由大页面支持的整个内存范围。这是确保没有其他预留耗尽操作系统分配的大页面池所必需的。这也意味着需要预先分配足够的大页面以在保留时支持整个内存范围，否则 JVM 将回退到使用正常页面。
要配置这种类型的大页面，首先检查可用的页面大小：
$ ls /sys/kernel/mm/hugepages/
hugepages-1048576kB  hugepages-2048kB

然后将您喜欢的页数配置为给定大小，如下所示：
$ echo 2500 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
这会尝试分配 2500 个 2 MB 的页面。应该始终读取实际存储的值，nr_hugepages以确保内核能够分配请求的数量。
默认情况下，JVM 将在尝试保留大页面时使用环境默认大页面大小，以查看您的系统默认大页面大小运行：
$ cat /proc/meminfo | grep Hugepagesize
Hugepagesize:       2048 kB

如果您想使用不同的大页面大小，可以通过设置 JVM 标志来完成LargePageSizeInBytes。例如，要使用 1 GB 的页面运行-XX:LargePageSizeInBytes=1g.
更多关于 HugeTLB 页的信息也可以在内核文档中找到。
 
两种方法各有利弊，选择哪一种取决于多个方面。THP 更易于设置和使用，但在使用 HugeTLB 页面时您有更多控制权。如果延迟是您最关心的问题，那么您可能应该使用 HugeTLB 页面，因为您永远不会等待操作系统释放足够的连续内存。作为替代方案，您可以将defragTHP 选项配置为在没有大页面可用时不停止，但这可能会带来吞吐量成本。如果内存占用是一个问题，THP 是避免必须预先提交整个 Java 堆的更好选择。
使用哪种类型的大页面取决于应用程序和环境，但在很多情况下，使用任何类型的大页面都会对性能产生积极影响。
 
Windows
在 Windows 上，配置步骤要容易一些，至少在较新的版本上是这样。运行要使用大页面的进程的用户需要具有在内存中锁定页面的权限。在 Windows 10 上，这是通过以下方式完成的：
  1. 运行gpedit.msc
  2. 在“计算机配置”>“Windows设置”>“安全设置”>“本地策略”下找到“用户权限分配”
  3. 找到“在内存中锁定页面”并双击它
  4. 单击“添加用户或组”并添加正确的用户
  5. 注销或重新启动以使更改生效

一旦授予此权限，JVM 将能够使用大页面（如果使用-XX:+UseLargePages. Windows 上的 JVM 大页面实现与 Linux 上的 HugeTLB 页面非常相似。由大页面支持的整个预留是预先提交的，以确保我们以后不会出现任何故障。
还有一个错误阻止 G1（默认 GC）在 Windows 上为大于 4 GB 的堆使用大页面。现在已修复此问题，并且继续使用G1运行大型Minecraft 服务器应该能够通过启用大页面获得不错的提升。
 
检查 JVM
一旦您的环境被正确配置并且您已经启用 Java 以使用大页面运行，那么验证JVM 是否真的使用了大页面是很好的。您当然可以使用您最喜欢的操作系统工具来检查这一点，但 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 上运行的，我们可以看到启用了大页面支持。Enabled (Explicit)这意味着使用了 HugeTLB 页面。如果使用-XX:+UseTransparentHugePages日志行运行将如下所示：
[0.030s][info][gc,init] Large Page Support: Enabled (Transparent)
以上仅显示是否启用了大页面，如果您想了解有关使用大页面的 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 的哪些部分由大页面支持的好方法。