何时关闭redis的透明大页面

Question

根据redis docs,建议禁用透明大页面.

如果在redis服务器和应用程序之间共享机器,指南是否相同.

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

Answer 1

把它关掉。问题在于 THP 如何移动内存以尝试保留或创建连续页面。一些应用程序可以容忍这一点，大多数数据库不能容忍，这会导致间歇性的性能问题，有些非常糟糕。无论如何，这并不是 Redis 独有的。

对于您的应用程序，尤其是 JAVA 应用程序，请设置真正的 HugePages，并且将透明的多样性排除在外。如果您这样做，请确保为应用程序和 redis 正确分配内存。尽管我不得不说，我可能不建议在同一个实例/服务器/虚拟机上同时运行应用程序和 redis。

Answer 2

关闭透明大页是一个坏主意，redis 不再推荐它。

您应该做的是确保transparent_hugepage 未设置为always。（这是最新版本的 redis 检查的内容。）您可以使用以下命令检查设置的当前值：

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

并像这样纠正它：

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

尽管可能不需要执行任何操作，但因为它madvise通常是最新 Linux 发行版中的默认设置。

一些背景：

透明_hugepage = 总是：可以强制应用程序使用大页面，除非他们选择使用 madvise 退出。这有很多问题并且很少启用。
透明_hugepage = never：不满足大页分配，即使应用程序使用 madvise 请求它
透明_hugepage = madvise：允许应用程序选择使用大页面。这通常是一个好主意，因为大页可以提高某些应用程序的性能，但此设置不会强制它们适用于不选择加入的应用程序，例如 redis 。

Answer 3

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

\n

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

\n

\n

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

\n

在提出这个问题 3 年后，Redis默认情况下获得了自行调用的配置disable-thp选项。prctl(PR_SET_THP_DISABLE, ...)

\n

/sys/kernel/mm/transparent_hugepage/enabled当设置为时，我的生产内存密集型流程的速度提高了 5-15% always。许多流行的桌面应用程序都从always透明大页面中受益匪浅。

\n

这就是为什么我无法欣赏那些用 Redis advi\xd1\x81e 垃圾邮件来禁用它们的“透明大页面”搜索结果。这是来自 Redis 的恐慌建议，而不是最佳实践。

\n