关闭它。问题在于THP如何移动内存来尝试保持或创建连续的页面。一些应用程序可以容忍这种情况，大多数数据库不能，它会导致间歇性的性能问题，有些相当糟糕。无论如何，这并不是Redis独有的。
对于你的应用程序，特别是JAVA应用程序，设置真实的的HugePages，不要让透明的页面出现在其中。如果你这样做了，只要确保你为应用程序和redis正确分配了内存。尽管我不得不说，我可能不建议在同一个示例/服务器/虚拟机上运行应用程序和redis。

关闭透明的hugepages是一个坏主意，和redis no longer recommends it。
您应该做的是确保transparent_hugepage未设置为always。（This is what recent versions of redis check for.）您可以使用以下命令检查设置的当前值：

$ cat /sys/kernel/mm/transparent_hugepage/enabled

然后像这样更正：

# echo madvise >/sys/kernel/mm/transparent_hugepage/enabled

虽然可能不需要任何操作，因为madvise是最近linux发行版中的默认设置。
一些背景：

• 透明_大页面=始终：可以强制应用程序使用hugepages，除非他们选择退出与mdvise。这有很多问题，很少启用。
• 透明_大页面=从不：不使用hugepages完成分配，即使应用程序使用madvise请求
• 透明_大页面=移动：允许应用程序选择加入hugepages。这通常是个好主意，因为hugepages可以提高某些应用程序的性能，但是这个设置并不强制应用程序加入hugepages，例如redis

搜索“透明大页面”会产生关于如何禁用它们的最高结果，这是相当烦人的，因为Redis和其他一些数据库无法在不降低性能的情况下处理透明大页面。
这些应用程序应执行以下操作之一：

• 使用prctl(PR_SET_THP_DISABLE, ...)调用来选择不使用透明的大页面。
• 由一个脚本启动，该脚本在fork/exec数据库进程之前为它们执行此调用。PR_SET_THP_DISABLE由子进程/线程继承，这正是当现有应用程序无法修改时的情况。

prctl(PR_SET_THP_DISABLE, ...)从Linux 3.15大约2014年就已经可用了，所以那些数据库几乎没有理由不提到这个解决方案，而是给他们的用户这个糟糕/恐慌的建议，为整个系统禁用透明的巨大页面。
在这个问题被问到3年后，Redis默认让disable-thp config option自己调用prctl(PR_SET_THP_DISABLE, ...)。
当/sys/kernel/mm/transparent_hugepage/enabled设置为always时，我的生产内存密集型进程的速度提高了5-15%，许多流行的桌面应用程序都从always透明的大页面中受益匪浅。
这就是为什么我不能欣赏那些“透明大页面”的搜索结果，这些搜索结果被Redis的建议禁用。这是Redis的“恐慌建议”，而不是"最佳实践“。

由于碎片整理成本的原因，THP强加的开销仅发生在内存分配期间。
如果你的redis示例有一个（接近）恒定的内存占用，你只能从THP中受益，同样的道理也适用于to java或任何其他自己做内存管理的长期服务，预先分配内存一次就可以受益。

当有一个内核参数可以 Boot 时，为什么要玩这样的回声游戏呢？
透明_大页面=从不