Question

根据redis docs，建议禁用透明大页面。

如果在redis服务器和应用程序之间共享计算机，指南是否相同。

此外，对于其他技术，我还读过guidance，在设置服务器时应禁用所有生产环境的THP。这种先发制人是否也适用于redis，或者在决定关闭THP之前必须首先严格监控延迟问题？

Answer 1

将其关闭。问题在于THP如何改变内存以尝试保持或创建连续的页面。有些应用程序可以容忍这种情况，大多数数据库都不能，它会导致间歇性的性能问题，有些非常糟糕。无论如何，这并不是Redis独有的。

对于您的应用程序，特别是如果它是JAVA，请设置真正的HugePages并保留透明变体。如果您这样做，请确保为应用程序和redis正确分配内存。虽然我不得不说，我可能不建议在同一个实例/服务器/虚拟机上运行app和redis。

Answer 2

搜索“透明大页面”会产生关于如何禁用它们的最高结果，这很烦人，因为 Redis 和其他一些数据库无法在不降低性能的情况下处理透明大页面。

这些应用程序应执行以下任一操作：

使用 prctl(PR_SET_THP_DISABLE, ...) 调用选择退出使用透明大页面。
由一个脚本启动，该脚本在 fork/exec 数据库进程之前调用它们。 PR_SET_THP_DISABLE 由子进程/线程在无法修改现有应用程序的情况下继承。

prctl(PR_SET_THP_DISABLE, ...) 自 2014 年左右的 Linux 3.15 开始可用，因此这些数据库几乎没有理由不提及此解决方案，而是向其用户提供这种糟糕/恐慌的建议，以禁用透明大页面整个系统。

在提出这个问题 3 年后，Redis 默认让 disable-thp config option 自行调用 prctl(PR_SET_THP_DISABLE, ...)。

当 /sys/kernel/mm/transparent_hugepage/enabled 设置为 always 时，我的生产内存密集型进程的运行速度提高了 5-15%，这就是为什么我无法欣赏那些用 Redis 发送垃圾邮件的“透明大页面”的搜索结果的原因。禁用它们。这个建议很糟糕。

Answer 3

由于碎片整理成本，THP施加的开销仅在内存分配期间发生。

如果您的redis实例具有（近）恒定的内存占用，则只能从THP中受益。 to java或执行自己的内存管理的任何其他长期服务也是如此。一次预分配内存并受益。

Answer 4

关闭透明的大页面是一个坏主意，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发行版中的默认设置。

一些背景：

transparent_hugepage =始终：可以强制应用程序使用大页面，除非它们与madvise一起退出。这有很多问题，很少启用。
transparent_hugepage =永不：即使应用程序使用madvise要求，也无法完成大页面的分配
transparent_hugepage = madvise：允许应用程序选择加入大页面。通常，这是一个好主意，因为大页面可以提高某些应用程序的性能，但是此设置不会在like redis未选择加入的应用程序上强制使用大页面

Answer 5

为什么在有内核参数的情况下播放这样的echo-game，你可以用它来启动？

transparent_hugepage =从不