因为安装MangoDB要禁用THP，就比较好奇原因，所以才有了以下。
Huge Pages（以下简称HP），又叫“大页”（编者注：你看我们搞IT的，翻译起来就是那么的直白生猛），或者叫“标准大页”、“传统大页”——这就是相对Transparent Huge Pages（以下简称THP）“透明大页”来的名字。
我们知道CPU读取数据，顺序一般是：一级缓存-->二级缓存-->内存-->硬盘（不严谨，但是大家都明白这个意思）。读取速度依次变慢。
抛开Cache不谈，我们做个不恰当的比喻，CPU就是售货员，负责拿货给客人，要想速度快，最好的办法就是把商品（程序的数据、指令等）放在柜台（内存）里，但是柜台毕竟有限，而且要装很多种商品（不同的程序），不可能完全放下，那么大量的商品还是会放在后面的仓库（硬盘）。
这样处理，问题：
A、柜台对所有商品是开放的。甲商品可以把柜台里放着的乙商品随意处置，乙商品就懵B了。
B、柜台空间不足，卖的甲商品一旦过多，就得把其他商品挪到仓库里，再把甲商品从仓库提出来放在柜台里。这一进一出，效率极其低下。
C、我们可以将程序分割成小份，先在内存处理A部分，然后从硬盘调取B部分，驻留在内存进行处理。但是现在的程序功能复杂，用户脑洞太大，程序员也无法预测处理完A部分之后，接下来一定就是B部分。
等等吧，以上这些内存的寻址、读取、清理等操作，要全靠程序员来处理，所以打击知道为什么程序员多秃顶了吧。
为了解决这些问题，不让程序员干预内存的处理，就有了虚拟内存技术。
简单地说，在硬盘划出一块，叫SWAP分区，跟物理内存一样，被系统当做内存对待，但毕竟不是真内存，故称虚拟内存。
OS把暂时用不到的数据，放入SWAP区，当要处理的数据不在物理内存中时，从硬盘再读取至内存。
各位看官会说，这和刚才我们说的问题C有什么区别？区别就在“地址”！
在问题C的处理中，程序必须知道数据在内存的地址（比如M1、M2、M9......），还要知道在硬盘的地址（比如D21、D22、D29......）。同一份数据，每次从硬盘读取到内存的地址都是随机的（D21的数据这次在M1，下次可能就在M9）。
而虚拟内存则是把内存、硬盘的地址统一编号（S1、S2、S3......），对于程序来说，这份数据在S3就在S3，不管它是在内存还是硬盘，我不care。
还有其他的好处，比如我们说到的问题A，虚拟内存就可以控制进程对内存的访问权限，再不能随意处理了。对于程序来说，可以分配连续的虚拟内存地址——哪怕物理地址不连续。通过页面调度（从硬盘读取数据至内存，从内存写数据至硬盘）算法——先进先出（FIFO）、最近最少使用（LRU）、最佳页面替换（OPT）等，尽量避免问题B中，装入装出大量数据造成的性能浪费。不再一一解释。
关键在于虚拟内存地址，它毕竟不是真实的地址，程序说我要S1的数据，CPU就必须给出真实的地址（M1或D21），这块工作是有Translation Lookaside Buffer（TLB）来做的，TLB通过页表（Page Table）这种数据结构，缓存了虚拟页与物理页的映射关系。打个比方，有点类似虚拟地址:物理地址这样的键值对（当然没那么简单，大家理解即可）。
但是当我们使用Oracle、MangoDB这样需要大内存的应用时，可想而知，这个页表会很大很大。我们知道Linux管理内存，是以4K为一个页面进行管理的。当数据很大的时候，除以4K，所需的页表也会越来越大，维护页表就变得很消耗资源。
举个例子，一个公务员如果想建立一个居民信息表，要是以家庭为单位，那么映射表就会很大，解决办法呢？我们就用小区为单位吧~~~
这就是“大页”（Huge Pages），更大的页！同样的数据，除以4K，需要多少条目，除以2M（HP默认的大小），又需要多少条目，不言而喻。
终于说到本文主题了，不过好像可说的也不多了。
THB相对于HB来说，区别主要在于HB是要预分配的，而THB则是由khugepaged进程进行动态分配。可想而知，对于DB这种内存操作频繁的应用，预分配的更省事，第一次搞好即可，不用每次现分配。Oracle就要求关闭Linux默认启用的THB。
今天是2019乙亥猪年初一，文章前两天就开始边查资料边写，很仓促，里面很多知识点没有写，比如虚拟内存、HB的优点、HB/TLB的各种操作都没有写，以后有机会再写吧。即便是文章写道的也肯定会有谬误，请大家批评指正。
祝大家新春玉快，阖家欢落~~~