禁用透明大页面 (THP) 的副作用/缺点是什么？

Question

我在 Redis 日志中收到关于延迟问题的警告，如下所示：

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel.
To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root

禁用透明大页面 (THP) 的副作用/缺点是什么？

在内核中默认启用它。

Answer 1

根据 digitalocean 的文章： Transparent Huge Pages and Alternative Memory Allocators: A Cautionary Tale

最近，我们的网站可靠性工程团队开始获得 提醒我们一些 Redis 实例的内存压力 工作集非常小。1 当我们开始深入研究这个问题时， 很明显，之后释放内存存在问题 初始分配，因为有相对较少的数量 键，但分配的内存量相对较大 redis 服务器进程。尽管最初看起来像泄漏，但 问题实际上是替代内存分配器之间的问题 和透明的大页面。

为什么需要禁用 THP？

当最近移至LD_PRELOAD jemalloc.so 的redis-server 进程开始使用大量内存时，这个兔子洞就开始了。最初的迹象表明，使用替代分配器可能是问题的一部分，因此我们开始挖掘。

事实证明，jemalloc(3) 广泛使用madvise(2) 来通知操作系统它已经完成了它之前拥有malloc 的内存范围。由于机器使用透明大页面，页面大小为2MB。因此，很多被标记为madvise(..., MADV_DONTNEED) 的内存都在远小于 2MB 的范围内。这意味着操作系统永远无法驱逐范围标记为 MADV_DONTNEED 的页面，因为必须不需要整个页面才能重用它。

因此，尽管最初看起来像是泄漏，但由于madvise(2) 和透明的大页面，操作系统本身无法释放内存。这导致机器上持续存在内存压力，redis-server 最终导致 OOM 被杀死。

根据Redis Latency Problems Troubleshooting Documentation：

必须从您的内核中禁用透明大页面。 使用echo never > /sys/kernel/mm/transparent_hugepage/enabled 禁用它们， 并重新启动您的 Redis 进程。

透明大页面引起的延迟

不幸的是，当 Linux 内核启用了透明大页时， 在使用 fork 调用后，Redis 会产生很大的延迟损失 为了持久化在磁盘上。巨大的页面是以下原因 问题：

1. 调用了 Fork，创建了两个共享大页面的进程。
2. 在繁忙的实例中，运行几个事件循环将导致命令针对几千页，导致几乎写入时复制 全过程记忆。
3. 这将导致大延迟和大内存使用。