Hugepages的前世今生 （二）

下面用例子来说明为什么使用传统的 4k大小的页表相比hugepages对大内存的管理效率会很低。

some facts: 在x86平台，一条PTE的大小为4Byte；而在x86_64平台， 一条PTE的大小为8Byte。

以下这种场景并不罕见：

Linux x86_64, SGA大小为100G， 使用常规的4k的page，连接到数据库的进程数约1000。

page table一共需要100×1024×1024K/4K=26214400条PTE；

那么26214400条PTE需要100×1024×1024K/4K×8Byte=209715200Byte=200M；

从而1000个进程需要100×1024×1024K/4K×8Byte×1000=209715200000Byte=200G。

计算出来的结果真是令人崩溃，但是事实上在你没有崩溃以前， 数据库就已经因为没有内存而崩溃了。

同样条件下，如果使用2M的hugepages进行对比， 则以上的计算方法变为：

page table一共需要100×1024M/2M=51200条PTE；

那么51200条PTE需要100×1024M/2M×8Byte=409600Byte=400K；

从而1000个进程需要100×1024M/2M×8Byte×1=409600Byte=400K。

是的，你没有看错，只要乘以1，而不是乘以1000。

综上，可以看到同样是1000个进程，同样是管理100G的SGA，结果却大不相同。

使用传统的4k大小的page开销竟然会达到惊人的200G；

而使用2M的hugepages，开销只有400K。

这其中不仅仅只是对于因为单个进程而言，2M page需要的PTE小于4K  page的PTE， 最大的一个原因是在于使用4K page的话，有多少进程使用SGA， 就需要多少套PTE，相反如果使用2M page则无论有多少进程使用SGA，共享的都是同一套PTE。

注： 此问题曾经困惑了我很长时间，在公司Linux PM的帮助下终于弄懂了这个算法，这里表示诚挚的感谢，当然希望对本文的读者能有一些帮助。

Hugepages really make some differents。