什么是禁用透明大页面(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. 这将导致大延迟和大量内存使用.