Linux HugePage 特性

Bertha 。 2021-10-19 15:28 247阅读 0赞

HugePage，就是指的大页内存管理方式。与传统的4kb的普通页管理方式相比，HugePage为管理大内存(8GB以上)更为高效。本文描述了什么是HugePage，以及HugePage的一些特性。

1、Hugepage的引入  
    操作系统对于数据的存取直接从物理内存要比从磁盘读写数据要快的多，但是物理内存是有限的，这样就引出了物理内存与虚拟内存的概念。虚拟内存就是为了满足物理内存的不足而提出的策略，它是利用磁盘空间虚拟出的一块逻辑内存，这部分磁盘空间Windows下称之为虚拟内存，Linux下被称为交换空间(Swap Space)。

对于这个大内存的管理(物理内存+虚拟内存)，大多数操作系统采用了分段或分页的方式进行管理。分段是粗粒度的管理方式，而分页则是细粒度管理方式，分页方式可以避免内存空间的浪费。相应地，也就存在内存的物理地址与虚拟地址的概念。通过前面这两种方式，CPU必须把虚拟地址转换成物理内存地址才能真正访问内存。为了提高这个转换效率，CPU会缓存最近的虚拟内存地址和物理内存地址的映射关系，并保存在一个由CPU维护的映射表中。为了尽量提高内存的访问速度，需要在映射表中保存尽量多的映射关系。

linux的内存管理采取的是分页存取机制，为了保证物理内存能得到充分的利用，内核会按照LRU算法在适当的时候将物理内存中不经常使用的内存页自动交换到虚拟内存中，而将经常使用的信息保留到物理内存。**通常情况下，Linux默认情况下每页是4K，这就意味着如果物理内存很大，则映射表的条目将会非常多，会影响CPU的检索效率。因为内存大小是固定的，为了减少映射表的条目，可采取的办法只有增加页的尺寸。因此Hugepage便因此而来。也就是打破传统的小页面的内存管理方式，使用大页面2m,4m,16m等等。如此一来映射条目则明显减少。**如果系统有大量的物理内存（大于8G），则物理32位的操作系统还是64位的，都应该使用Hugepage。

2、Hugepage的相关术语

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.

如前所述，page table也就是一种用于内存管理的实现方式，用于物理地址到虚拟之间的映射。因此对于内存的访问，先是访问Page Table，然后根据Page Table 中的映射关系，隐式的转移到物理地址来存取数据。

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.

CPU中的一块固定大小的cache，包含了部分page table的映射关系，用于快速实现虚拟地址到物理地址的转换。

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.

hugetlb 是TLB中指向HugePage的一个entry(通常大于4k或预定义页面大小)。 HugePage 通过hugetlb entries来实现，也可以理解为HugePage 是hugetlb page entry的一个句柄。

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.  
      一个类似于tmpfs的新的in-memory filesystem，在2.6内核被提出。

3、常见的错误概念  
WRONG: HugePages is a method to be able to use large SGA on 32-bit VLM systems   
RIGHT: HugePages is a method to have larger pages where it is useful for working with very large memory. It is both useful in 32- and 64-bit configurations

WRONG: HugePages cannot be used without USE\_INDIRECT\_DATA\_BUFFERS   
RIGHT: HugePages can be used without indirect buffers. 64-bit systems does not need to use indirect buffers to have a large buffer cache for the RDBMS instance and HugePages can be used there too.

WRONG: hugetlbfs means hugetlb   
RIGHT: hugetlbfs is a filesystem type \*\*BUT\*\* hugetlb is the mechanism employed in the back where hugetlb can be employed WITHOUT hugetlbfs

WRONG: hugetlbfs means hugepages   
RIGHT: hugetlbfs is a filesystem type \*\*BUT\*\* HugePages is the mechanism employed in the back (synonymously with hugetlb) where HugePages can be employed WITHOUT hugetlbfs.

4、Regular Pages 与 HugePages

a、Regular Pages

在下图中有两个不同的进程，两个进程对于内存的访问是首先访问本地的page table，而本地的page table又参照了system-wide table的page(也就是前面描述的TLB)，最终system-wide table中的entry指向了实际的物理地址。图中物理地址page size大小4kb。也可以看到进程1和进程2在system-wide table中都指向了page2，也就是同一个物理地址。Oracle sga中共享内存的使用会出现上述情形。

![1365490241_2196.jpg][]

b、Huge Pages

在下图中，本地的page table 与system page table中都包含了huge page属性。因此page table中的任意一个page可能使用了常规的page，  
也有可能使用了huge page。同样进程1和进程2都共享了其中的Hpage2。图中的物理内存常规的page size是4kb，huge page size 是4mb。

![1365490271_4369.jpg][]

\--Author : Robinson  
\--Blog   : [http://blog.csdn.net/robinson\_0612][http_blog.csdn.net_robinson_0612]

5、huge page 的大小  
huge page 的大小取决于所使用的操作系统的内核版本以及不同的硬件平台  
可以使用$grep Hugepagesize /proc/meminfo来查看huge page 的大小  
下面是不同平台常用的huge page 的大小。  
HW Platform                        Source Code Tree              Kernel 2.4           Kernel 2.6

\-----------------                        ---------------------                     ------------          -------------  
Linux x86 (IA32)                          i386                                  4 MB                  4 MB \*   
Linux x86-64 (AMD64, EM64T)     x86\_64                          2 MB                  2 MB   
Linux Itanium (IA64)                    ia64                                 256 MB               256 MB   
IBM Power Based Linux (PPC64)      ppc64/powerpc          N/A \*\*               16 MB   
IBM zSeries Based Linux            s390                                  N/A                   1 MB   
IBM S/390 Based Linux              s390                                   N/A                   N/A

6、使用huge page的优点  
对于较大的系统内存以及sga，使用hugepage可以极大程度的提高Oracle数据库性能。

a、Not swappable

HugePages are not swappable. Therefore there is no page-in/page-out mechanism overhead.HugePages are universally regarded as pinned.

无需交换。也就是不存在页面由于内存空间不足而存在换入换出的问题

b、Relief of TLB pressure  
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  
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  
Fewer TLB entries for the SGA also means more for other parts of the address space

减轻TLB的压力，也就是降低了cpu cache可缓存的地址映射压力。由于使用了huge page，相同的内存大小情况下，管理的虚拟地址数量变少。  
TLB entry可以包含更多的地址空间，cpu的寻址能力相应的得到了增强。

c、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.

降低page table负载，对于普通的page，每个entry需要64bytes进行管理，对于50gb的内存，管理这些entry，需要800mb的大小  
(50\*1024\*1024)kb/4kb\*64bytes/1024/1024=800mb。

d、Eliminated page table lookup overhead

Since the pages are not subject to replacement, page table lookups are not required.( 消除page table查找负载)

e、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.(提高内存的整体性能)

7、未正确配值huge page的风险  
基于大内存(>8GB)的管理，如果配值或正确配值huge page，可能存在下列不确定的隐性问题  
    HugePages not used (HugePages\_Total = HugePages\_Free) at all wasting the amount configured for   
    Poor database performance   
    System running out of memory or excessive swapping   
    Some or any database instance cannot be started   
    Crucial system services failing (e.g.: CRS)

8、基于2.6内核的配值步骤  
The kernel parameter used for HugePages is vm.nr\_hugepages which is based on the number of the pages. SLES9, RHEL4 and Asianux 2.0 are  examples of distributions with the 2.6 kernel. For the configuration, follow steps below:

a. Start instance(s)  
    b. Calculate nr\_hugepages using script from Document 401749.1  
    c. Set kernel parameter:  
            \# sysctl -w vm.nr\_hugepages=<value from above>  
         and make sure that the parameter is persistent to reboots. e.g. On SLES9:  
            \# chkconfig boot.sysctl on

d. Check available hugepages:  
            $ grep Huge /proc/meminfo

e. Restart instances  
    f. Check available hugepages:  
            $ grep Huge /proc/meminfo

9、注意事项  
a、HugePage使用的是共享内存，在操作系统启动期间被动态分配并被保留，因为他们不会被置换。  
b、由于不会被置换的特点，在使用hugepage的内存不能被其他的进程使用。所以要合理设置该值，避免造成内存浪费。  
c、对于只使用Oracle的服务器来说，把Hugepage设置成SGA(所有instance SGA之和)大小即可。  
d、如果增加HugePage或添加物理内存或者是当前服务器增加了新的instance以及SGA发生变化，应该重新设置所需的HugePage。  
e、reference: HugePages on Linux: What It Is... and What It Is Not... \[ID 361323.1\] To Bottom  
f、如何配置HugePage，请参考:[Linux 下配置 HugePages][Linux _ HugePages][ ][Link 1]

注：

1、大页的引入主要是可以减小page table的大小，减少cpu在内存管理上的时间消耗，从而提高性能。

查看page table 开销：

grep PageTables /proc/meminfo

2、支持大页需要内核配置`CONFIG_HUGETLBFS=y` 和`CONFIG_HUGETLB_PAGE=y，具体有关大页方面的配置和说明可以参考：`

https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

3、上面主要参照oracle数据库分析的hugepage，由于pg与oracle类似都是使用共享内存的形式，所以针对pg也是适用的。

1）下面说一下pg启用大页的方式：

pg中启用大页非常简单，pg中有huge\_pages参数，参数值有try，on和off。其中默认为try，数据库启动时，会尝试使用大页，如果失败会继续使用常规内存页的分配，如果配置为on，如果使用大页失败就会启动失败，选择off，则不使用大页。

2）估计大页分配的大小

设置大页大小可以通过内核参数vm.nr\_hugepages来实现，对于pg的大页大小判断可以在没有启用大页时，查看pg的postmaster的`VmPeak` 值，和系统默认单个huge page 大小。

$ head -1 $PGDATA/postmaster.pid
    4170
    $ grep ^VmPeak /proc/4170/status
    VmPeak:  6490428 kB
    $ grep ^Hugepagesize /proc/meminfo
    Hugepagesize:       2048 kB

6490428 / 2048=3169.154，所以大概需要3170个大页。

$sysctl -w vm.nr_hugepages=3170

关于大页大小的估计，也可以直接使用shared\_buffers来计算，直接通过shared\_buffers除以单个huge page 大小来计算。

如果系统中有其他程序需要使用大页，可以适量增大。为了避免重启后失效，可以添加到/etc/sysctl.conf文件里面。

有时候，即使设置了大页，也不能即使生效，需要重启一下操作系统。

可以通过下面命令来验证大页使用情况：

# grep Huge /proc/meminfo 
    HugePages_Total:  3170
    HugePages_Free:   3170
    HugePages_Rsvd:      0
    Hugepagesize:     2048 kB

参考：

https://yq.aliyun.com/articles/268503?spm=5176.100239.blogcont78155.24.715Ykf

https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

https://www.postgresql.org/docs/10/static/kernel-resources.html\#LINUX-HUGE-PAGES

下面的这篇文章几位技术牛人讲了一下huge page的优点和缺点：

https://yq.aliyun.com/articles/78155?spm=5176.100239.blogcont8482.17.YOs8AN

转载于:https://www.cnblogs.com/xiaotengyi/p/8118944.html

[1365490241_2196.jpg]: https://img-my.csdn.net/uploads/201304/09/1365490241_2196.jpg
[1365490271_4369.jpg]: https://img-my.csdn.net/uploads/201304/09/1365490271_4369.jpg
[http_blog.csdn.net_robinson_0612]: http://blog.csdn.net/robinson_0612?spm=5176.100239.blogcont268503.9.j8DnBf
[Linux _ HugePages]: http://blog.csdn.net/robinson_0612/article/details/8788825?spm=5176.100239.blogcont268503.10.j8DnBf
[Link 1]: http://blog.csdn.net/robinson_0612/article/details/8788825?spm=5176.100239.blogcont268503.11.j8DnBf