什么是禁用透明大页面（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

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

  

最近，我们的网站可靠性工程团队开始了   警告我们的一些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死亡。

按照Redis Latency Problems Troubleshooting Documentation：

  

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

     

透明大页面引发的延迟

     

不幸的是，当Linux内核启用了透明的大页面时，   在使用fork调用后，Redis会导致大的延迟惩罚   为了坚持在磁盘上。巨大的页面是以下原因   问题：

     

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