为JVM启用大页面支持

最近在看《Linux服务器性能调整》，书中第九章-Linux虚存的性能问题中提到了当代计算机体系结构都支持多种页面大小。大型页面可以改善高 性能计算及内存密集型应用的性能。回想起之前看IBM developmentworks上介绍websphere调优和oracle weblogic中tuning都提到了这一点，于是想记下一笔，不过网上正好看到ken Wu已经就此总结过了，于是转贴在此。红色部分为我添加的。

转自 Ken Wu`s Blog

原文链接 JVM优化之调整大内存分页(LargePage)

本文将从内存分页的原理，如何调整分页大小两节内容，向你阐述LargePage对JVM的性能有何提升作用，并在文末点明了大内分页的副作用。OK，让我们开始吧！

内存分页大小对性能的提升原理

首先，我们需要回顾一小部分计算机组成原理，这对理解大内存分页至于JVM性能的提升是有好处的。

什么是内存分页？
我们知道，CPU是通过寻址来访问内存的。32位CPU的寻址宽度是 0~0xFFFFFFFF ，计算后得到的大小是4G，也就是说可支持的物理内存最大是4G。

但在实践过程中，碰到了这样的问题，程序需要使用4G内存，而可用物理内存小于4G，导致程序不得不降低内存占用。
为了解决此类问题，现代CPU引入了 MMU（Memory Management Unit 内存管理单元）。

MMU 的核心思想是利用虚拟地址替代物理地址，即CPU寻址时使用虚址，由 MMU 负责将虚址映射为物理地址。
MMU的引入，解决了对物理内存的限制，对程序来说，就像自己在使用4G内存一样。

内存分页(Paging)是在使用MMU的基础上，提出的一种内存管理机制。它将虚拟地址和物理地址按固定大小（4K）分割成页(page)和页帧(page frame)，并保证页与页帧的大小相同。

这种机制，从数据结构上，保证了访问内存的高效，并使OS能支持非连续性的内存分配。
在程序内存不够用时，还可以将不常用的物理内存页转移到其他存储设备上，比如磁盘，这就是大家耳熟能详的虚拟内存。

在上文中提到，虚拟地址与物理地址需要通过映射，才能使CPU正常工作。
而映射就需要存储映射表。在现代CPU架构中，映射关系通常被存储在物理内存上一个被称之为页表(page table)的地方。

 

的page table在现代操作系统中由全局目录（PGD）-中间目录（PMD）-页表项（PTE）三层树构成，有时候不同书上图不一样但意思一样，只是画多画少。

进一步优化，引入TLB（Translation lookaside buffer，页表寄存器缓冲）
由上一节可知，页表是被存储在内存中的。我们知道CPU通过总线访问内存，肯定慢于直接访问寄存器的。
为了进一步优化性能，现代CPU架构引入了TLB，用来缓存一部分经常访问的页表内容。

对比 9.6 那张图，在中间加入了TLB。

为什么要支持大内存分页？
TLB是有限的，这点毫无疑问。当超出TLB的存储极限时，就会发生 TLB miss，之后，OS就会命令CPU去访问内存上的页表。如果频繁的出现TLB miss，程序的性能会下降地很快。

为了让TLB可以存储更多的页地址映射关系，我们的做法是调大内存分页大小。

如果一个页4M，对比一个页4K，前者可以让TLB多存储1000个页地址映射关系，性能的提升是比较可观的。

调整OS和JVM内存分页

在Linux和windows下要启用大内存页，有一些限制和设置步骤。

Linux：
限制：需要2.6内核以上或2.4内核已打大内存页补丁。
确认是否支持，请在终端敲如下命令：

# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB

如果有HugePage字样的输出内容，说明你的OS是支持大内存分页的。Hugepagesize就是默认的大内存页size。
接下来，为了让JVM可以调整大内存页size，需要设置下OS 共享内存段最大值 和 大内存页数量。

共享内存段最大值
建议这个值大于Java Heap size，这个例子里设置了4G内存。

# echo 4294967295 > /proc/sys/kernel/shmmax

注意在32位操作系统上这个值不能超过4GB

大内存页数量

# echo 154 > /proc/sys/vm/nr_hugepages

这个值一般是 Java进程占用最大内存/单个页的大小 ，比如java设置 1.5G，单个页 10M，那么数量为  1536/10 = 154。
注意：因为proc是内存FS，为了不让你的设置在重启后被冲掉，建议写个脚本放到 init 阶段(rc.local)。

更简便的方法是

echo "vm.nr_hugepages=154" >> /etc/sysctl.conf

通过下述命令来验证设置是否生效

grep HugePages_Total /proc/meminfo

结果应该是你之前设置的数值154

 

Windows:

限制：仅支持 windows server 2003 以上server版本

操作步骤:

1. Control Panel -> Administrative Tools -> Local Security Policy
2. Local Policies -> User Rights Assignment
3. 双击 “Lock pages in memory”, 添加用户和组
4. 重启电脑

注意: 需要管理员操作。

单个页大小调整

JVM启用时加参数 -XX:LargePageSizeInBytes=10m

如果JDK是在1.5 update5以前的，还需要手动加 -XX:+UseLargePages，作用是启用大内存页支持。

——————————————————————

其实除了JVM可以使用大页面提高性能，还有一种应用更符合内存密集型的场景，那就是数据库。数据库的调优中很早就有了这部分的建议。详见

Tuning and Optimizing Red Hat Enterprise Linux for Oracle 9i and 10g Databases

当中提到

In order that an Oracle database can use Huge Pages in RHEL 4, you also need to increase the ulimit parameter "memlock " for the oracle user in/etc/security/limits.conf if "max locked memory" is not unlimited or too small, see ulimit -a or ulimit -l . For example:

oracle           soft    memlock         1048576
oracle           hard    memlock         1048576

The memlock parameter specifies how much memory the oracle user can lock into its address space. Note that Huge Pages are locked in physical memory. The memlock setting is specified in KB and must match the memory size of the number of Huge Pages that Oracle should be able to allocate. So if the Oracle database should be able to use 512 Huge Pages, then memlock must be set to at least 512 * Hugepagesize , which is on my system 1048576 KB (512*1024*2). If memlock is too small, then no single Huge Page will be allocated when the Oracle database starts.

如果limits文件中有相应设置的话，需要检查一下，避免系统没有留出足够的内存（被cache、buffer占用了）

不过作者也提到了

我们生产环境大部分java应用都没调过large page。性能瓶颈也不是在jvm上。

文章里提到的优化，仅仅是实验性质的。

优化对我们来说，是一个循序渐进的过程。我们追求的是效果明显的优化方案，而不是什么都调优一把。

按我的经验，这些一般只是锦上添花而已