昨天老白讨论了Hugepages对PAGETABLE的影响，从对Hugepage和PATABLE的分析来看，对于多进程架构的使用大量共享内存、会话数较多的系统来说，Hugepage可以有效的减少PageTable的大小，节约系统内存，降低TLB的搜索开销。另外由于Hugepage是不能swap的，因此把共享内存放入Hugepage在系统内存出现换页的时候不用担心共享内存被换页。这些好处对于单进程多线程架构的应用效果就没有那么好，换句话说，单进程多线程架构的应用共享内存使用Hugepage的好处没有多进程架构应用多。另外由于Hugepage是需要手工管理的，因此针对多线程架构（比如Mysql、达梦等）的系统，使用Hugepage要从管理便捷性和有限的提升性能上做出选择。还有一点是，普通的Hugepage是需要应用程序在分配内存的时候加以指定的，我们要让应用系统使用Hugepage必须修改应用中的内存分配模块，对于一些早期并未考虑Hugepage的应用来说，存在应用升级的需求。Transparent Hugepages（THP）技术是为了解决普通Hugepage管理的缺点而研发的一种新技术，Transparent Hugepages支持从2M到4G的大页（根据CPU和操作系统的双重支持，不同的系统会有所不同），并且使用Hugepages是透明的，不需要应用重新开发。似乎是十分棒的技术，那么为什么Oracle 11.2的官方里不建议使用LINUX 6开始支持的Transparent HugePages？为什么这个看似十分好的技术在Oracle数据库中要谨慎使用呢？这个问题是和Linux的实际物理内存使用有关的。我们可能分配了某个内存给某个进程使用。不过如果这个内存仅仅是分配了，但是没有实际使用，那么这个内存实际上还是没有真正被占用的。这一点对于普通内存块还是HUGEPAGE都是一样的。比如我们有一个系统：
当数据库实例启动前，HUGEPAGE全部是FREE的。然后我们启动数据库实例，这个数据库实例我们配置了7gb的SGA_TARGET，初始化的DB_CACHE加上SHARED POOL的大小大约是6.5GB：
好像只有200多个页被使用了，其他页还是空闲状态。我们针对数据库进行加压，再看内存的变化：
我们发现free的HUGEPAGE页面数量减少了。而且随着这个应用的持续运行，FREE的页面数趋于稳定，但是远远没有达到7GB或者6.5GB的大小。也就是说，虽然被ORACLE SGA占用的内存，如果没有真正被使用到，那么这部分内存实际上并没有从LINUX内核中获取到。只有真正使用到这部分内存的时候，linux才会真正分配这部分内存。普通的HUGEPAGE是预先占用的，在操作系统中会直接占据一个连续的内存空间，虽然没有分配，但是是被保护起来的。而使用transparent huagepages的时候，物理内存中还没有实际把这部分内存保护起来。一旦Oracle的SGA要使用这部分内存的时候，如果物理内存中有足够的大页直接分配，则可以进行分配，如果无法实现分配那么就分配普通的4K页。为了确保THP能够尽可能分配大页，那么就需要在对LINUX的内存进行碎片整理和内存回收，从而确保内存中有可分配大页的连续内存空间，这些都是通过khugepaged等后台进程来实现的。当如果系统中无足够的大页可供分配的时候，就需要通过CACHE DROP或者SWAP的方式释放足够的内存给THP使用。因此在使用THP的系统中，经常会出现一些性能的毛刺，也就是说，如果在大规模内存压缩和碎片整理的时候，系统的整体性能会下降，khugepaged、kcompactd、defrag等进程会占用大量的CPU资源，使系统出现一定程度的卡顿，对于不同负载的系统这个卡顿可能持续数秒甚至数分钟。
在一个负载较大，会话数十分多，SGA十分庞大的系统中，遇到各种风险的机会较大，可能会导致一些性能问题，甚至导致RAC实例宕机。从一些常见的导致RAC集群故障的BUG上看，大多数都是与SWAP等导致CRS集群心跳超时有关。因此Oracle建议使用普通的HUGEPAGE管理，而不使用Transparent hugepages。
THP的另外一个缺点是如果我只使用很小的内存，但是分配了一个大页，那么就会造成内存的浪费。因此对于应用系统来说，使用THP还是要十分慎重。
把THP的参数设置为madvise是一种选择，设置为madvise的时候，普通的THP申请是关闭的，不过如果我们强制申请大页，是被允许的。最后一个THP的问题是换页，如果我们要把一个1GB的HUGEPAGE交换出去，那么将会是一个灾难，交换带来的各种开销可能会让你的系统卡顿几十秒。
