简单聊聊HUGEPAGE

如果要回答这些问题，我们必须了解HUGEPAGE是什么，可能很多朋友都知道普通的LINUX内存页是4K的，也就是说1M内存需要映射为256个页面。而HUGEPAGE每个页面是2M以上（不同的内核版本支持HUGEPAGE页面的大小不同，一般是2M-256M）,比如：

上面例子中的HUGEPAGE就是2M大小。那么HUGEPAGE和普通内存页的使用有什么差异呢？当然一次性访问4K和一次性访问2M内存的性能是不存在太大的差异的，这是INTEL CPU的结构决定的。而最大的问题在于，使用不同的页大小，PAGETABLE的大小是不同的。因此，如果使用较小的页面，那么PAGETABLE会比较大。当然如果只有一份PAGETABLE，那么大不了也就多占用一些内存而已。这个PAGETABLE不是只有一份，第二个是每个进程都会有一份PAGETABLE。这样问题就来了，如果我们系统中有几千个会话，那么PAGETABLE就十分巨大了。我们做个简单的计算，比如，一个96G SGA的数据库，PAGETABLE的大小大约为144M，如果我们的系统中只有100个会话，那么大约占用14.4G的虚拟内存空间，如果有1000个会话，那么就会占用144G的虚拟内存，甚至比SGA还大。这种内存占用带来的系统换页、内存碎片化等等问题，在某些场景下就会变得十分严重。

因为共享内存的使用，同时使用共享内存的会话数量很大的情况下，一个不是特别大的物理内存区域的PAGETABLE的数量会随着会话数的增加而增加，从而导致PAGETABLE达到一个海量的大小。从上面的分析我们也可以得到一个结论，如果你的SGA比较大，同时会话数比较多，那么使用HUGEPAGE就一定会有很好的效果。否则HUGEPAGE带来的性能提升不会太明显。

再衍生一下，不仅仅是Oracle数据库，所有使用较大的共享内存，同时进程数量十分巨大的系统都会存在类似的问题。对于共享内存使用HUGEPAGE都能解决这方面的问题。弄明白了了HUAGEPAGE，下面我们就要来讨论一下Transparent HugePages的问题了。普通的HUGEPAGE管理模式是十分麻烦的，需要手工设置HUGEPAGE的数量，如果共享内存超过了HUGEPAGE的大小，那么就无法使用配置好的HUGEPAGE，必须手工加大HUGEPAGE的数量，并且重启操作系统。这种情况下，Transparent Hugepages技术就登场了。

上图的蓝色区域中的DirectMapxx就是系统中各种大小页面的可用容量评估值。也就是说大页不需要提前设置好，而是可用透明的使用。如果SGA需要100G的内存，2M的大页和4K的小页可以根据系统的内存情况动态的使用，这样就避免了HUGEPAGE动态管理不方便的问题。虽然透明大页可以解决普通大页管理的弊端，不过这种透明大页管理的使用更为复杂，对应用有更为严格的要求。在某些环境中，有可能使用透明大页带来一些负面的影响。比如在Oracle数据库11g的环境中，已知的由于透明大页引起的BUG就不少，特别是在RAC环境中会引起一些GCS/GES的性能问题，因此Oracle官方建议在Oracle 11g中不要使用透明大页。综上所述，具体是否使用透明大页，还是要看具体的情况了。