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被普遍認為是固定在RAM中的。
· Relief of TLB pressure:
o Hugepge uses fewer pages to cover the physical address space, so the size of “book keeping” (mapping from the virtual to the physical address) decreases, so it requiring fewer entries in the TLB
o TLB entries will cover a larger part of the address space when use HugePages, there will be fewer TLB misses before the entire or most of the SGA is mapped in the SGA
o Fewer TLB entries for the SGA also means more for other parts of the address space
減輕TLB的壓力
Hugepge使用較少的頁面來覆蓋物理地址空間，因此“保留書簽”（從虛擬地址到物理地址的映射）的大小減少，因此在TLB中要求較少的條目
當使用HugePages時，TLB條目將涵蓋更大的地址空間，對於SGA中的全部或大部分的內存映射，TLB未命中將會大大減少。
SGA需要更少的TLB條目意味着TLB中可以有更多的條目來保存其他地址空間。
TLB是直接緩存虛擬地址到物理地址的緩存表，用於提升性能，省去查找page table從而減少開銷，但是如果出現的大量的TLB miss，必然會給系統的性能帶來較大的負面影響，尤其對於連續的讀操作。從第二篇文章中我們知道如果使用hugepages能大量減少PTE的數量，也就意味着訪問同樣多的內容需要的PTE會更少，而通常TLB的槽位是有限的，一般只有512個，所以更少的PTE也就意味着更高的TLB的命中率。
· Decreased page table overhead: Each page table entry can be as large as 64 bytes and if we are trying to handle 50GB of RAM, the pagetable will be approximately 800MB in size which is practically will not fit in 880MB size lowmem (in 2.4 kernels - the page table is not necessarily in lowmem in 2.6 kernels) considering the other uses of lowmem. When 95% of memory is accessed via 256MB hugepages, this can work with a page table of approximately 40MB in total. See also Document 361468.1.
減少頁表的開銷：每個頁表條目可以高達64字節，如果我們50GB的RAM保存在頁表（page table）當中，那么頁表（page table）大小大約為800MB，實際上對於lowmem來說，考慮到lowmem的其他用途，880MB大小是不合適的（在2.4內核當中 ,page tabel在低於2.6的內核當中不是必須的）， lowmem中通過256MB的hugepages訪問95％的內存時，可以使用大約40MB的頁表。 另見文檔361468.1。
· Eliminated page table lookup overhead: Since the pages are not subject to replacement, page table lookups are not required.
減少頁表查詢的開銷：PTE的數量減少，那么使得很多頁表的查詢就不需要了，並且更少的PTE使得頁表的查詢更快。如果TLB miss，則可能需要額外三次內存讀取操作才能將線性地址翻譯為物理地址。
· Faster overall memory performance: On virtual memory systems each memory operation is actually two abstract memory operations. Since there are fewer pages to work on, the possible bottleneck on page table access is clearly avoided.
提升內存訪問的整體性能：使用虛擬內存，每一次對內存的訪問實際上都是由兩次抽象的內存操作組成。如果只要使用更少的頁面，那么原本在頁表訪問的瓶頸也得以避免
HugePages Reservation
The HugePages reservation feature is fully implemented in 2.6.17 kernel, and thus EL5 (based on 2.6.18) has this feature. The alloc_huge_page() is improved for this. (See kernel source mm/hugetlb.c)
From /usr/share/doc/kernel-doc-2.6.18/Documentation/vm/hugetlbpage.txt:
HugePages_Rsvd is short for "reserved," and is the number of hugepages for which a commitment to allocate from the pool has been made, but no allocation has yet been made. It's vaguely analogous to overcommit.
This feature in the Linux kernel enables the Oracle Database to be able to allocate hugepages for the sublevels of the SGA on-demand. The same behaviour is expected for various Oracle Database versions that are certified on EL5.
HugePages and Oracle 11g Automatic Memory Management (AMM)
The AMM and HugePages are not compatible. One needs to disable AMM on 11g to be able to use HugePages. See Document 749851.1 for further information.
在Linux中， kswapd是負責內核頁面交換管理的一個守護進程，它的職責是保證Linux內存管理操作的高效。當物理內存不夠時，它就會變得非常aggressive，有些情況下能占用單核CPU的100%. kswapd 進程負責確保內存空間總是在被釋放中，它監控內核中的pages_high和pages_low閥值。如果空閑內存的數值低於pages_low,則每次 kswapd 進程啟動掃描並嘗試釋放32個free pages.並一直重復這個過程,直到空閑內存的數值高於 pages_high。kswapd 進程完成以下幾個操作:
o 如果該頁處於未修改狀態,則將該頁放置回空閑列表中.
o 如果該頁處於已修改狀態並可備份回文件系統,則將頁內容寫入到磁盤.
o 如果該頁處於已修改狀態但沒有任何磁盤備份,則將頁內容寫入到swap device.
標准大頁的配置查看
查看標准大頁（Huage Pages)的頁面大小：
[root@DB-Server ~]$ grep Hugepagesize /proc/meminfo
Hugepagesize: 2048 kB
確認標准大頁（傳統大頁/大頁/HuagePage）是否配置、並在使用的方法：
[oracle@DB-Server ~]$ cat /proc/sys/vm/nr_hugepages
0
[oracle@DB-Server ~]$ grep -i HugePages_Total /proc/meminfo
HugePages_Total: 0
如果HugePages_Total為0，意味着標准大頁（大頁、傳統大頁）沒有設置或使用。nr_hugepages為0，意味着標准大頁沒有設置。
標准大頁的一些內核參數。如下所示：
[oracle@DB-Server ~]$ more /etc/issue
Red Hat Enterprise Linux Server release 5.7 (Tikanga)
Kernel \r on an \m
[oracle@DB-Server ~]$ grep Huge /proc/meminfo
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
[root@mylnx02 ~]# more /etc/issue
Red Hat Enterprise Linux Server release 6.6 (Santiago)
Kernel \r on an \m
[root@mylnx02 ~]# grep Huge /proc/meminfo
AnonHugePages: 18432 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
AnonHugePages: 匿名 HugePages 數量。Oracle Linux 6.5 中已刪除此計數器。與透明 HugePages 有關。
HugePages_Total: 分配的頁面數目，和Hugepagesize相乘后得到所分配的內存大小
HugePages_Free: 從來沒有被使用過的Hugepages數目。即使oracle sga已經分配了這部分內存，但是如果沒有實際寫入，那么看到的還是Free的。這是很容易誤解的地方（池中尚未分配的 HugePages 數量。）
HugePages_Rsvd: 已經被分配預留但是還沒有使用的page數目。在Oracle剛剛啟動時，大部分內存應該都是Reserved並且Free的，隨着ORACLE SGA的使用，Reserved和Free都會不斷的降低
HugePages_Surp: “surplus”的縮寫形式，表示池中大於/proc/sys/vm/nr_hugepages 中值的 HugePages 數量。剩余 HugePages 的最大數量由 /proc/sys/vm/nr_overcommit_hugepages 控制。此值為0的情況很常見
Hugepagesize: 頁面大小
HugePages_Free – HugePages_Rsvd 這部分是沒有被使用到的內存，如果沒有其他的oracle instance，這部分內存也許永遠都不會被使用到，也就是被浪費了。HugePages_Total-HugePages_Free+HugePages_Rsvd 就是目前實例需要的頁面數量.
如何設置標准大頁（Huge Page）的大小呢？一般都是修改內核參數nr_hugepages。在/etc/sysctl.conf配置文件中設置參數vm.nr_hugepages
# echo "vm.nr_hugepages=512" >> /etc/sysctl.conf
下面我們來介紹一下，在64位Linux服務器下為ORACLE數據庫設置標准大頁的基本步驟，具體需要根據實際情況作出調整。關於如何配置標准大頁，可以參考官方文檔HugePages on Oracle Linux 64-bit (文檔 ID 361468.1)或文檔（Configuring HugePages for Oracle on Linux (x86-64))來演示一下如何設置Huge Pages。
步驟1：在/etc/security/limits.conf文件中添加memlock的限制，注意該值略微小於實際物理內存的大小（單位為KB）。比如物理內存是64GB，可以設置為如下：
如果這里的值超過了SGA的需求，也沒有不利的影響。如果使用了Oracle Linux的oracle-validated包，或者Exadata DB compute則會自動配置這個參數。下面來看看一個實際測試環境，內存為16G
[root@mylnx02 ~]# free -m
total used free shared buffers cached
Mem: 16077 9520 6556 0 37 766
-/+ buffers/cache: 8716 7361
Swap: 14015 0 14015
那么我們修改/etc/security/limits.conf，設置memlock的值為16384000（16077*1024）
vi /etc/security/limits.conf
* soft memlock 16384000
* hard memlock 16384000
步驟2：重新登錄安裝Oracle產品的賬號並驗證memlock。如下所示，當前測試環境的賬號為oracle
[oracle@mylnx02 ~]$ ulimit -l
16384000
步驟3： 11g中禁用AMM 如果ORACLE 11g要使用標准大頁，就必須禁用AMM(Automatic Memory Management)，如果是ORACLE 10g則可以忽略該步驟。
[oracle@DB-Server ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Fri Oct 27 14:43:12 2017
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show parameter memory_target;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
memory_target big integer 1552M
SQL> show parameter memory_max_target;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
memory_max_target big integer 1552M
SQL>
SQL> alter system set memory_target=0 scope=both;
SQL> alter system set memory_max_target=0 scope=spfile;
如果Oracle 是11g以后的版本，那么默認創建的實例會使用Automatic Memory Management (AMM)的特性，該特性與HugePage不兼容。在設置HugePage之前需要先禁用AMM。設置初始化參數MEMORY_TARGET 和MEMORY_MAX_TARGET 為0即可。
使用AMM的情況下，所有的SGA 內存都是在/dev/shm 下分配的，因此在分配SGA時不會使用HugePage。這也是AMM 與HugePage不兼容的原因。
另外：默認情況下ASM instance 也是使用AMM的，但因為ASM 實例不需要大SGA，所以對ASM 實例使用HugePages意義不大。
如果我們要使用HugePage，那么就必須先確保沒有設置MEMORY_TARGET/ MEMORY_MAX_TARGET參數。
步驟4：確保你所有的ORACLE數據庫實例都已經啟動（包括ASM實例），然后運行hugepages_settings.sh（具體參考Mos文檔Document 401749.1，腳本內容如下）獲取內核參數vm.nr_hugepages的大小。
#! /bin/bash
#
# hugepages_settings.sh
#
# Linux bash script to compute values for the
# recommended HugePages/HugeTLB configuration
# on Oracle Linux
#
# Note: This script does calculation for all shared memory
# segments available when the script is run, no matter it
# is an Oracle RDBMS shared memory segment or not.
#
# This script is provided by Doc ID 401749.1 from My Oracle Support
# http://support.oracle.com
# Welcome text
echo "
This script is provided by Doc ID 401749.1 from My Oracle Support
(http://support.oracle.com) where it is intended to compute values for
the recommended HugePages/HugeTLB configuration for the current shared
memory segments on Oracle Linux. Before proceeding with the execution please note following:
* For ASM instance, it needs to configure ASMM instead of AMM.
* The 'pga_aggregate_target' is outside the SGA and
you should accommodate this while calculating SGA size.
* In case you changes the DB SGA size,
as the new SGA will not fit in the previous HugePages configuration,
it had better disable the whole HugePages,
start the DB with new SGA size and run the script again.
And make sure that:
* Oracle Database instance(s) are up and running
* Oracle Database 11g Automatic Memory Management (AMM) is not setup
(See Doc ID 749851.1)
* The shared memory segments can be listed by command:
# ipcs -m
Press Enter to proceed..."
read
# Check for the kernel version
KERN=`uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`
# Find out the HugePage size
HPG_SZ=`grep Hugepagesize /proc/meminfo | awk '{print $2}'`
if [ -z "$HPG_SZ" ];then
echo "The hugepages may not be supported in the system where the script is being executed."
exit 1
fi
# Initialize the counter
NUM_PG=0
# Cumulative number of pages required to handle the running shared memory segments
for SEG_BYTES in `ipcs -m | cut -c44-300 | awk '{print $1}' | grep "[0-9][0-9]*"`
do
MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
if [ $MIN_PG -gt 0 ]; then
NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`
fi
done
RES_BYTES=`echo "$NUM_PG * $HPG_SZ * 1024" | bc -q`
# An SGA less than 100MB does not make sense
# Bail out if that is the case
if [ $RES_BYTES -lt 100000000 ]; then
echo "***********"
echo "** ERROR **"
echo "***********"
echo "Sorry! There are not enough total of shared memory segments allocated for
HugePages configuration. HugePages can only be used for shared memory segments
that you can list by command:
# ipcs -m
of a size that can match an Oracle Database SGA. Please make sure that:
* Oracle Database instance is up and running
* Oracle Database 11g Automatic Memory Management (AMM) is not configured"
exit 1
fi
# Finish with results
case $KERN in
'2.2') echo "Kernel version $KERN is not supported. Exiting." ;;
'2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
'2.6') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
'3.8') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
'3.10') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
'4.1') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
esac
# End
[root@mylnx02 ~]# ./hugepages_settings.sh
This script is provided by Doc ID 401749.1 from My Oracle Support
(http://support.oracle.com) where it is intended to compute values for
the recommended HugePages/HugeTLB configuration for the current shared
memory segments on Oracle Linux. Before proceeding with the execution please note following:
* For ASM instance, it needs to configure ASMM instead of AMM.
* The 'pga_aggregate_target' is outside the SGA and
you should accommodate this while calculating SGA size.
* In case you changes the DB SGA size,
as the new SGA will not fit in the previous HugePages configuration,
it had better disable the whole HugePages,
start the DB with new SGA size and run the script again.
And make sure that:
* Oracle Database instance(s) are up and running
* Oracle Database 11g Automatic Memory Management (AMM) is not setup
(See Doc ID 749851.1)
* The shared memory segments can be listed by command:
# ipcs -m
Press Enter to proceed...
Recommended setting: vm.nr_hugepages = 4098
Step 5：在/etc/sysctl.conf文件中設置vm.nr_hugepages參數
[root@mylnx02 ~]# vi /etc/sysctl.conf
vm.nr_hugepages=4098
Step 6： 關閉所有的數據庫實例並重啟服務器。
Step 7： 驗證配置是否正確，如下所示：
[oracle@mylnx02 ~]$ grep HugePages /proc/meminfo
HugePages_Total: 4098
HugePages_Free: 3439
HugePages_Rsvd: 3438
HugePages_Surp: 0
為了確保HugePages配置的有效性，HugePages_Free值應該小於HugePages_Total 的值，並且有一定的HugePages_Rsvd的值。
The values in the output will vary. To make sure that the configuration is valid, the HugePages_Free value should be smaller than HugePages_Total and there should be some HugePages_Rsvd. HugePages_Rsvd counts free pages that are reserved for use (requested for an SGA, but not touched/mapped yet).
The sum of Hugepages_Free and HugePages_Rsvd may be smaller than your total combined SGA as instances allocate pages dynamically and proactively as needed.
Oracle 11.2.0.3以及以后版本，可以通過檢查警報日志來驗證是否對數據庫實例啟用了大頁面。啟動實例時，您應在警報日志中參數列表前面看到如下內容：
****************** Large Pages Information *****************
Total Shared Global Region in Large Pages = 28 GB (100%)
Large Pages used by this instance: 14497 (28 GB)
Large Pages unused system wide = 1015 (2030 MB) (alloc incr 64 MB)
Large Pages configured system wide = 19680 (38 GB)
Large Page size = 2048 KB
另外，可以通過以下參數控制數據庫對HugePage的使用方式(11gr2之后)：
use_large_pages = {true/only/false/auto}
默認值是true，如果系統設置Hugepages的話，SGA會優先使用hugepages，有多少用多少。如果設置為false， SGA就不會使用hugepages。如果設置為only 如果hugepages大小不夠的話，數據庫實例是無法啟動的。設置為auto，這個選項會觸發oradism進程重新配置linux內核，以增加hugepages的數量。一般設置為true。
SQL> alter system set use_large_pages=true scope=spfile sid='*';
啟用透明大頁
啟用透明大頁非常簡單，可以參考這篇博客Linux 關於Transparent Hugepages的介紹， 這里不做贅述。
參考資料：
https://help.marklogic.com/Knowledgebase/Article/View/16/0/linux-huge-pages-and-transparent-huge-pages
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=361468.1&id=401749.1
http://www.oracle.com/technetwork/cn/articles/servers-storage-dev/hugepages-2099009-zhs.html
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=500381499574891&id=361323.1&_afrWindowMode=0&_adf.ctrl-state=lxb6cxp3_100
https://developers.redhat.com/blog/2014/03/10/examining-huge-pages-or-transparent-huge-pages-performance/
https://oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64
https://access.redhat.com/documentation/zh-CN/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-transhuge.html
https://blogs.oracle.com/database4cn/linux-64hugepage
https://docs.oracle.com/cd/E11882_01/install.112/e41961/memry.htm#CBAFIFGJ