為什麼這麼設計（Why’s THE Design）是一系列關於計算機領域中程序設計決策的文章，我們在這個系列的每一篇文章中都會提出一個具體的問題並從不同的角度討論這種設計的優缺點、對具體實現造成的影響。如果你有想要了解的問題，可以在文章下面留言。
內存是計算機的重要資源，雖然今天大多數的服務對內存的需求都沒有那麼高，但是資料庫以及 Hadoop 全家桶這些服務卻是消耗內存的大戶，它們在生產環境動輒佔用 GB 和 TB 量級的內存來提升計算的速度，Linux 作業系統為了更好、更快地管理這些內存並降低開銷引入了很多策略，我們今天要介紹的是 HugePages，也就是大頁[^1]。
絕大多數的 CPU 架構都支持更大的頁面，只是不同作業系統會使用不同的術語，例如：Linux 上的 HugePages、BSD 上的 SuperPages 以及 Windows 上的 LargePages，這些不同的術語都代表著類似的大頁面功能。
圖 1 - CPU 架構和更大的頁面我們都知道 Linux 會以頁為單位管理內存，而默認的頁面大小為 4KB，雖然部分處理器會使用 8KB、16KB 後者 64KB 作為默認的頁面大小，不過 4KB 仍然是作業系統的默認頁面配置的主流[^2]，雖然 64KB 的頁面是 4KB 的 16 倍，但是與最小 2MB 的 HugePages 相比，64KB 的頁面實在是不夠大，更不用說默認的 4KB 了：
圖 2 - 默認和大頁面大小2MB 一般都是 HugePages 的默認大小，在 arm64 和 x86_64 的架構上甚至支持 1GB 的大頁面，是 Linux 默認頁面大小的 262,144 倍，我們可以使用如下所示的命令查看當前機器上 HugePages 的相關信息：
$ 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 卻可以在以下幾個方面降低內存頁面的管理開銷：
更大的內存頁能夠減少內存中的頁表層級，這不僅可以降低頁表的內存佔用，也能降低從虛擬內存到物理內存轉換的性能損耗；更大的內存頁意味著更高的緩存命中率，CPU 有更高的機率可以直接在 TLB（Translation lookaside buffer）中獲取對應的物理地址；更大的內存頁可以減少獲取大內存的次數，使用 HugePages 每次可以獲取 2MB 的內存，是 4KB 的默認頁效率的 512 倍；因為進程的地址空間都是虛擬的，所以 CPU 和作業系統需要記錄頁面和進程之間的對應關係，作業系統中的頁面越多，我們也就需要花費更多的時間在如下所示的五層頁表結構中查找虛擬內存對應的物理內存，我們會根據虛擬地址依次訪問頁表中的目錄（Directory）最終查找到對應的物理內存：
圖 3 - 默認頁的五層頁表如上圖所示，如果我們使用 Linux 中默認的 4KB 內存頁，那麼 CPU 在訪問對應的內存時需要分別讀取 PGD、PUD、PMD 和 PTE 才能獲取物理內存，但是 2MB 的大內存可以減少目錄訪問的次數：
圖 4 - 頁表與大頁因為 2MB 的內存頁佔用了 21 位的地址，所以我們也不再需要五層頁表中的 PTE 結構，這不僅能夠減少翻譯虛擬地址時訪問頁表的次數，還能夠降低頁表的內存佔用。
CPU 總可以通過上述複雜的目錄結構找到虛擬頁對應的物理頁，但是每次翻譯虛擬地址時都使用上述結構是非常昂貴的操作，作業系統使用 TLB 作為緩存來解決這個問題，TLB 是內存管理組件（Memory Management Unit）的一個部分，其中緩存的頁表項可以幫助我們快速翻譯虛擬地址：
圖 5 - TLB更大的內存頁面意味著更高的緩存命中率，因為 TLB 緩存的容量是一定的，它只能緩存指定數量的頁面，在這種情況下，緩存 2MB 的大頁能夠為系統提高緩存的命中率，從而提高系統的整體性能。
除了較少頁表項和提高緩存命中率之外，使用更大的頁面還可以提高內存的訪問效率，對於相同的 1GB 內存，使用 4KB 的內存頁需要系統處理 262,144 次，但是使用 2MB 的大頁卻只需要 512 次，這可以將系統獲取內存所需要的處理次數降低幾個數量級。
鎖定內存使用 HugePages 可以鎖定內存，禁止作業系統的內存交換和釋放。Linux 系統提供了交換分區（Swap）機制，該機制會在內存不足時將一部分內存頁從內存拷貝到磁碟上，釋放內存頁佔用的內存空間，而當對應的內存進程訪問時又會被交換到內存中，這種機制能夠為進程構造一種內存充足的假象，但是也會造成各種問題。
圖 6 - 交換分區我們在 為什麼 NUMA 會影響程序的延遲 一文中就介紹過 Swap 在開啟 NUMA 時可能會影響資料庫的性能[^5]，系統中偶然發生的 Swap 並不是不可以接受的，但是頻繁地讀寫磁碟會顯著地降低作業系統的運行速度。
HugePages 與其他內存頁不同，它是由系統工程師預先在作業系統上使用命令分配的，當進程通過 mmap 或者其他系統調用申請大頁時，它們得到的都是預先分配的資源。Linux 中的 HugePages 都被鎖定在內存中，所以哪怕是在系統內存不足時，它們也不會被 Swap 到磁碟上，這也就能從根源上杜絕了重要內存被頻繁換入和換出的可能[^6]。
REHL 6 引入了透明大頁（Transparent Huge Pages、THP），它是一個可以自動創建、管理和使用大頁的抽象層，能夠為系統管理員和開發者隱藏了大頁使用時的複雜性，但是不推薦在資料庫以及類似負載中開啟。[^7]
總結隨著單機內存越來越大、服務消耗的內存越來越多，Linux 和其他作業系統都引入了類似 HugePages 的功能，該功能可以從以下兩個方面提升資料庫等佔用大量內存的服務的性能：
HugePages 可以降低內存頁面的管理開銷，它可以減少進程中的頁表項、提高 TLB 緩存的命中率和內存的訪問效率；HugePages 可以鎖定內存，禁止作業系統的內存交換和釋放，不會被交換到磁碟上為其它請求讓出內存；雖然 HugePages 的管理相對比較複雜，需要系統管理員額外做出特定的配置，但是對於特定類型的工作負載，它確定能夠起到降低管理開銷和鎖定內存的作用，從而提高系統的性能。到最後，我們還是來看一些比較開放的相關問題，有興趣的讀者可以仔細思考一下下面的問題：
透明大頁（Transparent Huge Pages、THP）可能會造成哪些問題？手動管理系統中的 HugePages 有哪些優點？如果對文章中的內容有疑問或者想要了解更多軟體工程上一些設計決策背後的原因，可以在博客下面留言，作者會及時回複本文相關的疑問並選擇其中合適的主題作為後續的內容。
推薦閱讀圖是怎麼畫的