一、記憶體分頁大小為何會提升效能

首先，我們需要回顧一小部分計算機組成原理，這對理解大記憶體分頁至於JVM效能的提升是有好處的。

1、什麼是記憶體分頁？ 我們知道，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)的地方。 如下圖：

從這張圖中，可以清晰地看到CPU與頁表，實體記憶體之間的互動關係。

進一步優化，引入TLB（Translation lookaside buffer，頁表暫存器緩衝） 由上一節可知，頁表是被儲存在記憶體中的。我們知道CPU通過匯流排訪問記憶體，肯定慢於直接訪問暫存器的。 為了進一步優化效能，現代CPU架構引入了TLB，用來快取一部分經常訪問的頁表內容。 如下圖： 加入了TLB實體記憶體之間的互動關係

對比 9.6 那張圖，在中間加入了TLB。

2、為什麼要支援大記憶體分頁？

TLB是有限的，這點毫無疑問。當超出TLB的儲存極限時，就會發生 TLB miss，之後，OS就會命令CPU去訪問記憶體上的頁表。如果頻繁的出現TLB miss，程式的效能會下降地很快。

為了讓TLB可以儲存更多的頁地址對映關係，我們的做法是調大記憶體分頁大小。

如果一個頁4M，對比一個頁4K，前者可以讓TLB多儲存1000個頁地址對映關係，效能的提升是比較可觀的。

3、調整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

大記憶體頁數量

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

這個值一般是 Java程序佔用最大記憶體/單個頁的大小 ，比如java設定 1.5G，單個頁 10M，那麼數量為 1536/10 = 154。

注意：因為proc是記憶體FS，為了不讓你的設定在重啟後被沖掉，建議寫個指令碼放到 init 階段(rc.local)。

Windows: 限制：僅支援 windows server 2003 以上server版本 操作步驟:

Control Panel -> Administrative Tools -> Local Security Policy
Local Policies -> User Rights Assignment

雙擊 “Lock pages in memory”, 新增使用者和組 重啟電腦 注意: 需要管理員操作。

單個頁大小調整 JVM啟用時加引數 -XX:LargePageSizeInBytes=10m 如果JDK是在1.5 update5以前的，還需要手動加 -XX:+UseLargePages，作用是啟用大記憶體頁支援。

二、大記憶體分頁的副作用

因為每頁size變大了，導致JVM在計算Heap內部分割槽（perm, new, old）記憶體佔用比例時，會出現超出正常值的劃分。最壞情況下是，某個區會多佔用一個頁的大小。不過後續jvm版本也在調整這個策略。

一般情況，不建議將頁size調得太大，4-64M，是可以接受的（預設是4M）。為了合理設定這個值，你應該對你的系統做一下benchmark。

說實話，網上我見過調得最猛的，有調到256M，從benchmark報表上看，效能不是太壞。如果你有64位的大記憶體機器，不妨嘗試一下。

另外，網上有很多GC調優的文章內容中都有提到 LargePageSizeInBytes，但未提任何OS限制。在OS不支援的情況下，設定這個引數，這個引數將僅僅是個擺設。