Hugepages的前世今生 (二)

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

*

沪ICP备14014813号

沪公网安备 31010802001379号