記憶體是計算機的重要資源，雖然今天大多數的服務對記憶體的需求都沒有那麼高，但是資料庫以及 Hadoop 全家桶這些服務卻是消耗記憶體的大戶，它們在生産環境動辄占用 GB 和 TB 量級的記憶體來提升計算的速度，Linux 作業系統為了更好、更快地管理這些記憶體并降低開銷引入了很多政策，我們今天要介紹的是 HugePages，也就是大頁[^1]。
絕大多數的 CPU 架構都支援更大的頁面，隻是不同作業系統會使用不同的術語，例如：Linux 上的 HugePages、BSD 上的 SuperPages 以及 Windows 上的 LargePages，這些不同的術語都代表着類似的大頁面功能。
$ cat /proc/meminfo | grep Huge
AnonHugePages: 71680 kB
ShmemHugePages: 0 kB
FileHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
通過上面的輸出結果，我們可以看到目前機器上的大頁面預設大小為 2MB 并且大頁面的數量也為 0，即沒有程序在申請或者使用大頁。各位讀者可以在 Linux 嘗試執行上述指令，如果機器上沒有做過額外的配置，那麼使用上述指令得到的輸出與這裡也不會有太大的差别。
/proc/sys/vm/nr_hugepages
中存儲的資料就是大頁面的數量，雖然在預設情況下它的值都是 0，不過我們可以通過更改該檔案的内容申請或者釋放作業系統中的大頁：
$ echo 1 > /proc/sys/vm/nr_hugepages
$ cat /proc/meminfo | grep HugePages_
HugePages_Total: 1
HugePages_Free: 1
...
在 Linux 中，與其他記憶體的申請和釋放方式相同，我們可以在向
mmap
系統調用中傳入
MAP_HUGETLB
标記申請作業系統的大頁并使用
munmap
釋放記憶體[^3]，使用如下所示的代碼片段可以在作業系統中申請 2MB 的大頁：
size_t s = (2UL * 1024 * 1024);
char *m = mmap(
NULL, s, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB /* flags */,
-1, 0
);
munmap(m, s);
雖然 HugePages 的申請方式與預設的記憶體相差不多，但是它實際上是作業系統單獨管理的特殊資源，Linux 會在
/proc/meminfo
中單獨展示 HugePages 的相關資料，而容器編排系統 Kubernetes 也會認為大頁是不同于記憶體的獨立資源，如下所示的 Pod 也需要單獨申請大頁資源[^4]：
apiVersion: v1
kind: Pod
metadata:
name: huge-pages-example
spec:
containers:
- name: example
...
volumeMounts:
- mountPath: /hugepages-2Mi
name: hugepage-2mi
- mountPath: /hugepages-1Gi
name: hugepage-1gi
resources:
limits:
hugepages-2Mi: 100Mi
hugepages-1Gi: 2Gi
memory: 100Mi
requests:
memory: 100Mi
volumes:
- name: hugepage-2mi
emptyDir:
medium: HugePages-2Mi
- name: hugepage-1gi
emptyDir:
medium: HugePages-1Gi
作為 Linux 從 2.6.32 引入的新特性，HugePages 能夠提升資料庫、Hadoop 全家桶等占用大量記憶體的服務的性能，該特性對于常見的 Web 服務以及後端服務沒有太多的幫助，反而可能會影響服務的性能，我們在這篇文章中會介紹 HugePages 為什麼能夠提升資料庫等服務的性能：
- HugePages 可以降低記憶體頁面的管理開銷；
- HugePages 可以鎖定記憶體，禁止作業系統的記憶體交換和釋放；
管理開銷
雖然 HugePages 的開啟大都需要開發或者運維工程師的額外配置，但是在應用程式中啟用 HugePages 卻可以在以下幾個方面降低記憶體頁面的管理開銷：
- 更大的記憶體頁能夠減少記憶體中的頁表層級，這不僅可以降低頁表的記憶體占用，也能降低從虛拟記憶體到實體記憶體轉換的性能損耗；
- 更大的記憶體頁意味着更高的緩存命中率，CPU 有更高的幾率可以直接在 TLB（Translation lookaside buffer）中擷取對應的實體位址；
- 更大的記憶體頁可以減少擷取大記憶體的次數，使用 HugePages 每次可以擷取 2MB 的記憶體，是 4KB 的預設頁效率的 512 倍；
因為程序的位址空間都是虛拟的，是以 CPU 和作業系統需要記錄頁面和程序之間的對應關系，作業系統中的頁面越多，我們也就需要花費更多的時間在如下所示的五層頁表結構中查找虛拟記憶體對應的實體記憶體，我們會根據虛拟位址依次通路頁表中的目錄（Directory）最終查找到對應的實體記憶體：
如上圖所示，如果我們使用 Linux 中預設的 4KB 記憶體頁，那麼 CPU 在通路對應的記憶體時需要分别讀取 PGD、PUD、PMD 和 PTE 才能擷取實體記憶體，但是 2MB 的大記憶體可以減少目錄通路的次數：
因為 2MB 的記憶體頁占用了 21 位的位址，是以我們也不再需要五層頁表中的 PTE 結構，這不僅能夠減少翻譯虛拟位址時通路頁表的次數，還能夠降低頁表的記憶體占用。
CPU 總可以通過上述複雜的目錄結構找到虛拟頁對應的實體頁，但是每次翻譯虛拟位址時都使用上述結構是非常昂貴的操作，作業系統使用 TLB 作為緩存來解決這個問題，TLB 是記憶體管理元件（Memory Management Unit）的一個部分，其中緩存的頁表項可以幫助我們快速翻譯虛拟位址：
更大的記憶體頁面意味着更高的緩存命中率，因為 TLB 緩存的容量是一定的，它隻能緩存指定數量的頁面，在這種情況下，緩存 2MB 的大頁能夠為系統提高緩存的命中率，進而提高系統的整體性能。
除了較少頁表項和提高緩存命中率之外，使用更大的頁面還可以提高記憶體的通路效率，對于相同的 1GB 記憶體，使用 4KB 的記憶體頁需要系統處理 262,144 次，但是使用 2MB 的大頁卻隻需要 512 次，這可以将系統擷取記憶體所需要的處理次數降低幾個數量級。
鎖定記憶體
使用 HugePages 可以鎖定記憶體，禁止作業系統的記憶體交換和釋放。Linux 系統提供了交換分區（Swap）機制，該機制會在記憶體不足時将一部分記憶體頁從記憶體拷貝到磁盤上，釋放記憶體頁占用的記憶體空間，而當對應的記憶體程序通路時又會被交換到記憶體中，這種機制能夠為程序構造一種記憶體充足的假象，但是也會造成各種問題。
我們在 [為什麼 NUMA 會影響程式的延遲 ]一文中就介紹過 Swap 在開啟 NUMA 時可能會影響資料庫的性能[^5]，系統中偶然發生的 Swap 并不是不可以接受的，但是頻繁地讀寫磁盤會顯著地降低作業系統的運作速度。
HugePages 與其他記憶體頁不同，它是由系統工程師預先在作業系統上使用指令配置設定的，當程序通過
mmap
或者其他系統調用申請大頁時，它們得到的都是預先配置設定的資源。Linux 中的 HugePages 都被鎖定在記憶體中，是以哪怕是在系統記憶體不足時，它們也不會被 Swap 到磁盤上，這也就能從根源上杜絕了重要記憶體被頻繁換入和換出的可能[^6]。
REHL 6 引入了透明大頁（Transparent Huge Pages、THP），它是一個可以自動建立、管理和使用大頁的抽象層，能夠為系統管理者和開發者隐藏了大頁使用時的複雜性，但是不推薦在資料庫以及類似負載中開啟。[^7]
總結
随着單機記憶體越來越大、服務消耗的記憶體越來越多，Linux 和其他作業系統都引入了類似 HugePages 的功能，該功能可以從以下兩個方面提升資料庫等占用大量記憶體的服務的性能：
- HugePages 可以降低記憶體頁面的管理開銷，它可以減少程序中的頁表項、提高 TLB 緩存的命中率和記憶體的通路效率；
- HugePages 可以鎖定記憶體，禁止作業系統的記憶體交換和釋放，不會被交換到磁盤上為其它請求讓出記憶體；
- 透明大頁（Transparent Huge Pages、THP）可能會造成哪些問題？
- 手動管理系統中的 HugePages 有哪些優點？