原文链接: 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