Linux下的大頁分為兩種類型：標準大頁（Huge Pages）和透明大頁（Transparent Huge Pages）。Huge Pages有時候也翻譯成大頁/標準大頁/傳統大頁，它們都是Huge Pages的不同中文翻譯名而已，順帶提一下這個，免得有人被這些名詞給混淆、誤導了。Huge Pag... ...
Linux下的大頁分為兩種類型：標準大頁（Huge Pages）和透明大頁（Transparent Huge Pages）。Huge Pages有時候也翻譯成大頁/標準大頁/傳統大頁，它們都是Huge Pages的不同中文翻譯名而已，順帶提一下這個，免得有人被這些名詞給混淆、誤導了。Huge Pages是從Linux Kernel 2.6後被引入的。目的是使用更大的記憶體頁面（memory page size） 以適應越來越大的系統記憶體，讓操作系統可以支持現代硬體架構的大頁面容量功能。透明大頁（Transparent Huge Pages）縮寫為THP，這個是RHEL 6（其它分支版本SUSE Linux Enterprise Server 11, and Oracle Linux 6 with earlier releases of Oracle Linux Unbreakable Enterprise Kernel 2 (UEK2)）開始引入的一個功能。具體可以參考官方文檔。這兩者有啥區別呢？這兩者的區別在於大頁的分配機制，標準大頁管理是預分配的方式，而透明大頁管理則是動態分配的方式。相信有不少人將Huge Page和Transparent Huge Pages混為一談。目前透明大頁與傳統HugePages聯用會出現一些問題，導致性能問題和系統重啟。Oracle 建議禁用透明大頁（Transparent Huge Pages）。在 Oracle Linux 6.5 版中，已刪除透明 HugePages。
標準大頁（HuagePage）英文介紹
HugePages is a feature integrated into the Linux kernel with release 2.6. It is a method to have larger pages where it is useful for working with very large memory. It can be useful for both 32-bit and 64-bit configurations. HugePage sizes vary from 2MB to 256MB, depending on the kernel version and the hardware architecture. For Oracle Databases, using HugePages reduces the operating system maintenance of page states, and increases TLB (Translation Lookaside Buffer) hit ratio.
RHEL的官方文檔對傳統大頁（Huge Pages）和透明大頁（Transparent Huge Pages）這兩者的描述如下(https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-transhuge.html)
Huge pages can be difficult to manage manually, and often require significant changes to code in order to be used effectively. As such, Red Hat Enterprise Linux 6 also implemented the use of transparent huge pages(THP). THP is an abstraction layer that automates most aspects of creating, managing, and using huge pages.
THP hides much of the complexity in using huge pages from system administrators and developers. As the goal of THP is improving performance, its developers (both from the community and Red Hat) have tested and optimized THP across a wide range of systems, configurations, applications, and workloads. This allows the default settings of THP to improve the performance of most system configurations. However, THP is not recommended for database workloads.
傳統大頁很難手動管理, 而且通常需要對代碼進行重大更改才能有效地使用。因此, 紅帽企業 Linux 6 實現引入了透明大頁面 (THP)。THP 是一個抽象層, 可以自動創建、管理和使用傳統大頁的大多數方面。
THP為系統管理員和開發人員減少了很多使用傳統大頁的複雜性, 因為THP的目標是改進性能, 因此其它開發人員 (來自社區和紅帽) 已在各種系統、配置、應用程式和負載中對 THP 進行了測試和優化。這樣可讓 THP 的預設設置改進大多數系統配置性能。但是, 不建議對資料庫工作負載使用 THP。
註：THP 目前只能映射非同步記憶體區域，比如堆和棧空間
我們知道，x86架構使用的是虛擬記憶體架構，其允許定址範圍超過硬體中的可用物理記憶體。這通過允許每個進程擁有自己可定址的記憶體來實現。該進程認為此記憶體是專供自己使用的。這稱為進程的虛擬記憶體。實際上，此記憶體可以是實際駐留於RAM 晶元上的物理記憶體，也可以是存儲在物理磁碟上被稱作交換區或分頁區的專用區域中。進程不知道虛擬記憶體是存儲在RAM 中還是磁碟上；記憶體由操作系統管理。如果所需記憶體超過可用物理記憶體，操作系統會將一些記憶體移出到分頁區。這種活動效率極低，是導致性能問題的常見原因。由於磁碟的存取速度遠低於RAM，“分頁”的進程會遇到顯著的性能問題。
另外，隨著硬體的飛速發展，伺服器的記憶體越來越大，系統中使用的記憶體越多，管理該記憶體所需的資源也就越多。對於Linux 操作系統，通過 Linux kswapd 進程和頁表（Page Table）記憶體結構（針對系統中存在的每個進程包含一條記錄）實現記憶體管理。每條記錄包含進程使用的每頁虛擬記憶體及其物理地址（RAM 或磁碟）。通過使用處理器的TLB（ Translation Lookaside Buffer CPU中一小塊緩存）為該進程提供幫助。操作系統使用頁表條目管理系統中進程所用的記憶體。在 Linux 中，執行此管理的操作系統進程被稱作kswapd，可在操作系統工具中找到。TLB 緩存將緩存頁表條目來提高性能。典型的 TLB 緩存可保存 4 到 4096 個條目。對於數百萬甚至數十億個頁表條目，這種緩存就不夠用了。
當大量記憶體被用於ORACLE資料庫或其他應用時，操作系統將消耗大量資源來管理虛擬地址到物理地址轉換，其結果往往是一個非常大的頁表結構（Page Table）。由於每條頁表條目包含進程正在使用的所有記憶體頁面的虛擬地址到物理地址的轉換，因此對於非常大的系統全局區 (SGA)，每個進程的頁表條目都可能很大。舉個例子，我們的一個測試伺服器，記憶體為64GB，SGA_TARGET為32G，如果沒有使用傳統大頁，頁表結構（PageTables）大小為1573080 kB，接近1.5G大小了。您可以看到，要管理的頁面數量巨大。這將導致顯著的性能開銷。
# grep PageTables /proc/meminfo
PageTables: 1573080 kB
這些就是傳統大頁為什麼會被引入的原因。 引入它能解決什麼問題呢？記憶體是由塊管理，即眾所周知的頁面。我們知道，在Linux 64位系統裡面,預設記憶體是以4K的頁面（Page）來管理的。也就是說一個頁面有 4096 位元組。1MB 記憶體等於 256 個頁面。2MB記憶體等於512個頁面。管理這些記憶體的消耗就比較大。CPU 有內嵌的記憶體管理單元TLB，這些單元中包含這些頁面列表，每個頁面都使用頁表條目。頁表（Page Table）用來存放虛擬記憶體和物理記憶體頁對應關係的記憶體結構。如果page size較小，那麼相應的頁表記憶體結構就會比較大。而Hugepages的預設值page size為2M，是4KB的500倍，所以可以大大減小Page Table的大小。通過啟用 HugePages使用大頁面，可以用一個頁表條目代表一個大頁面，而不是使用許多條目代表較小的頁面，從而可以管理更多記憶體，減少操作系統對頁面狀態的維護並提高 TLB 緩存命中率。註意，Hugepagesize的大小預設為2M，這個也是可以調整的。區間範圍為2MB to 256MB。
如果上面這段解釋還不夠清晰、徹底，那麼看看下麵這段摘抄的解釋：
大多數操作系統採用了分段或分頁的方式進行管理。分段是粗粒度的管理方式，而分頁則是細粒度管理方式，分頁方式可以避免記憶體空間的浪費。相應地，也就存在記憶體的物理地址與虛擬地址的概念。通過前面這兩種方式，CPU必須把虛擬地址轉換程物理記憶體地址才能真正訪問記憶體。為了提高這個轉換效率，CPU會緩存最近的虛擬記憶體地址和物理記憶體地址的映射關係，並保存在一個由CPU維護的映射表中。為了儘量提高記憶體的訪問速度，需要在映射表中保存儘量多的映射關係。Linux的記憶體管理採取的是分頁存取機制，為了保證物理記憶體能得到充分的利用，內核會按照LRU演算法在適當的時候將物理記憶體中不經常使用的記憶體頁自動交換到虛擬記憶體中，而將經常使用的信息保留到物理記憶體。通常情況下，Linux預設情況下每頁是4K，這就意味著如果物理記憶體很大，則映射表的條目將會非常多，會影響CPU的檢索效率。因為記憶體大小是固定的，為了減少映射表的條目，可採取的辦法只有增加頁的尺寸。因此Hugepage便因此而來。也就是打破傳統的小頁面的記憶體管理方式，使用大頁面2M,4M等。如此一來映射條目則明顯減少。TLB 緩存命中率將大大提高。
而ORACLE為什麼要使用標準大頁（Huge Pages）來提高性能？因為ORACLE資料庫使用共用記憶體(SGA)來管理可以共用的一些資源;比如shared pool中存儲了共用的SQL語句及執行計劃,buffer pool中存儲了數據塊。對這些資源的訪問,其實就是ORACLE使用OS的API來訪問記憶體資源的過程。記憶體操作理應/通常意義上都是很快的,這時候Oracle資料庫可以很正常的工作。但是有些情況下也會出現性能問題：
a)如果SGA內的某一部分被swap到硬碟上,那麼再次訪問它,就需要花非常多的時間。
b)如果OS本身的記憶體非常的大,那麼管理/訪問到我們需要的記憶體的過程就需要更長時間。
在這些情況下,我們往往會碰到諸如latch/mutex/library cache lock[pin]/row cache lock的問題.
Linux下HugePage可以解決由以上兩種問題引發的性能波動。
我們知道，在Linux 64位系統裡面,預設記憶體是以4K的頁面（Page）來管理的,當系統有非常多的記憶體的時候,管理這些記憶體的消耗就比較大;而HugePage使用2M大小的頁面來減小管理開銷。HugePage管理的記憶體並不能被Swap，這就避免了Swap引發的資料庫性能問題。所以，如果您的系統經常碰到因為swap引發的性能問題的系統毫無疑問需要啟用HugePage。另外，OS記憶體非常大的系統也需要啟用HugePage。但是具體多大就一定需要使用HugePage？這並沒有定論，有些文檔曾經提到12G以上就推薦開啟，我們強烈建議您在測試環境進行了充分的測試之後，再決定是否在生產環境應用HugePage。
當然，任何事情都是有兩面性的，HugePage也有些小缺點。第一個缺點是它需要額外配置，但是這完全是可以忽略的。另外， 如果使用了HugePage，11g新特性 AMM（Automatic Memory Management）就不能使用了，但是ASMM（Automatic Shared Memory Management）仍然可以繼續使用。
下麵是一些相關名詞以及Huge Pages的特征等等。大部分都是RHEL官網或Mos上相關英文資料以及對應的部分翻譯：
· Page Table: A page table is the data structure of a virtual memory system in an operating system to store the mapping between virtual addresses and physical addresses. This means that on a virtual memory system, the memory is accessed by first accessing a page table and then accessing the actual memory location implicitly.
· TLB: A Translation Lookaside Buffer (TLB) is a buffer (or cache) in a CPU that contains parts of the page table. This is a fixed size buffer being used to do virtual address translation faster.
· hugetlb: This is an entry in the TLB that points to a HugePage (a large/big page larger than regular 4K and predefined in size). HugePages are implemented via hugetlb entries, i.e. we can say that a HugePage is handled by a "hugetlb page entry". The 'hugetlb" term is also (and mostly) used synonymously with a HugePage (See Note 261889.1). In this document the term "HugePage" is going to be used but keep in mind that mostly "hugetlb" refers to the same concept.
· hugetlbfs: This is a new in-memory filesystem like tmpfs and is presented by 2.6 kernel. Pages allocated on hugetlbfs type filesystem are allocated in HugePages.
HugePages in 2.4 Kernels
The HugePages feature is backported to some 2.4 kernels. Kernel versions 2.4.21-* has this feature (See Note 311504.1 for the distributions with 2.4.21 kernels) but it is implemented in a different way. The feature is completely available. The difference from 2.6 implementation is the organization within the source code and the kernel parameters that are used for configuring HugePages. See Parameters/Setup section below.
Advantages of HugePages Over Normal Sharing Or AMM (see below)
· Not swappable: HugePages are not swappable. Therefore there is no page-in/page-out mechanism overhead.HugePages are universally regarded as pinned.
不可交換：HugePages不可交換。 因此沒有頁面換入/頁面換出的機制開銷.HugePages被普遍認為是固定在
