原文链接： http://www.dbaleet.org/the_cirle_of_hugepages_part_2
下面用例子来说明为什么使用传统的 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。
Comment