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

Question

我在Redis Log中收到针对延迟问题的警告，如下所示：

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

正如Per digitalocean的文章： 透明的巨大页面和替代记忆分配器：一个警示故事

最近，我们的站点可靠性工程团队开始收到关于我们的Redis实例的内存压力的警报，这些实例具有非常小的工作集.1当我们开始深入研究这个问题时，很明显在初始分配之后存在释放内存的问题，因为那里是一个相对较少的密钥，但redis-server进程分配的内存相对较多。 尽管最初看起来像是泄漏，但问题实际上是替代内存分配器和透明大页面之间的问题。

为什么需要禁用THP？

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

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

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

作为Per Redis Latency问题故障排除文档 ：

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

透明的大页面引起的延迟

不幸的是，当Linux内核启用了透明的大页面时，在使用fork调用以便在磁盘上保留之后，Redis会导致大的延迟损失。 巨大的页面是导致以下问题的原因：

1. 调用Fork，创建具有共享大页面的两个进程。
2. 在繁忙的实例中，一些事件循环运行将导致命令以几千个页面为目标，导致几乎整个进程内存的写入副本。
3. 这将导致大延迟和大量内存使用。