Redis内存碎片:深度解析与优化策略

本文已收录至GitHub,推荐阅读 👉 Java随想录

微信公众号:Java随想录

原创不易,注重版权。转载请注明原作者和原文链接

在我们探究和优化Redis性能的过程中,「Redis内存碎片」是一个不可忽视的话题。

这篇文章将深入研究这个看似微不足道,但实际上对Redis运行效率产生重要影响的问题。首先,让我们揭开Redis内存碎片的神秘面纱,理解它的本质及其为何成为我们必须面对的挑战。

内存碎片如何产生的

Redis内存碎片主要是因为Redis数据存储和回收过程中的内存管理问题导致的。

Redis分配内存时,会根据需要申请一段连续的内存空间。但当Redis删除或修改数据时,释放的内存空间并不一定能被立即重新利用,尤其是当这些空闲内存空间大小不一致时,就可能导致内存碎片的出现。

为了提高内存使用的效率,Redis内部使用内存分配器来对内存的申请和释放进行管理。Redis使用的内存分配器默认是「jemalloc」。

而内存分配器是按照固定大小来分配内存的,并不是完全按照程序申请的内存大小来进行分配。

比如程序申请一个20字节的内存,内存分配器会分配一个32字节的内存空间,这么做是为了减少分配次数。redis会申请不同大小的内存空间来存储不同业务不同类型的数据,由于内存按照固定大小分配且会比实际申请的内存要大一些,这个过程中会产生内存碎片。

举个生活中的例子,帮助大家理解:

假设你正在整理一间图书馆。图书馆的书架就像是Redis储存数据的内存空间。每本书都代表不同大小的数据。刚开始时,你把所有的书都按照大小放好。小书在一侧,大书在另一侧。这样你可以有效地利用书架的空间,也方便找书。

但是,如果你需要移除一些书(删除某些数据),然后又加入新的书(新增数据),就可能出现问题了。例如,你移除了一些大书,把它们的位置空出来,然后把新的小书放进去。这样下来,原本属于大书的空间,现在只被小书部分占用,剩余的空白就成了“内存碎片”。

又或者你有一堆新的大书要放,但书架上只有分散的小书的空位,无法容纳这些大书。这个时候你可能需要重新排列整个书架(类似于Redis的内存整理)去腾出连续的大片空间来摆放这些新的大书。

总结来说:当数据不断删除和新增时,内存中空出的位置可能无法完全匹配新数据的大小,导致产生未被利用的“碎片”空间,这就是内存碎片。

内存分配器

Redis 使用内存分配器来管理其在运行期间需要使用的内存资源。可以是libc、jemalloc、tcmalloc。默认是jemalloc。

要指定 Redis 使用哪个内存分配器,你需要在编译 Redis 时做出选择。通常在执行 make 命令时可以通过 MALLOC 参数来指定。例如,如果你想使用 jemalloc,你可以像这样编译 Redis:make MALLOC=jemalloc

jemalloc在64位系统中,将内存空间划分为小、大、巨大三个范围。每个范围内又划分了许多小的内存块单位,存储数据的时候,会选择大小最合适的内存块进行存储。

jemalloc划分的内存单元如下图所示:

也就是说Redis是以指定大小的块为单位进行连续内存分配的,而不是按需分配的,Redis 会根据申请的内存最接近的固定值分配相应大小的空间。

这就像你有不同的箱子,为了装东西,你需要找一个体积最接近的箱子来装。但是装进去后,你发现还有空间可以放一些小东西,就无需再找箱子了。

但是,这种分配空间的方式会带来一定程度的内存碎片。我们可以把固定大小的划分空间看成不同体积的箱子,每种箱子里的空间不同程度上都会有剩余。这些剩余的空间就是内存碎片。

怎么看是否有内存碎片

我们登陆到Redis服务器上,执行以下命令,这会返回一段描述Redis内存使用情况的文本。

redis> info memory

我们会看到类似如下的信息:

在这里,我们主要关注的是名为mem_fragmentation_ratio的字段,它显示了Redis内存碎片的比例。

如果mem_fragmentation_ratio大于1,那就表示存在内存碎片。这个值越大,内存碎片就越多。如果该值非常接近1或者小于1,则表示内存碎片很少或者没有。

计算公式为:

mem_fragmentation_ratio = used_memory_rss / used_memory

其中:

  • used_memory_rss:代表Redis进程占用的总物理内存大小(包括码区、数据区和堆栈等),单位是字节。
  • used_memory:代表Redis分配器申请的内存总量,也就是从操作系统角度看进程实际使用的虚拟内存空间,单位是字节。

碎片率的意义

mem_fragmentation_ratio的不同值,说明不同的情况。

  • 大于1:说明内存有碎片,通常在1到1.5之间是正常的。
  • 大于1.5:说明内存碎片率比较大,需要考虑是否要进行内存碎片清理,要引起重视。
  • 小于1:说明已经开始使用交换内存,也就是使用硬盘了,正常的内存不够用了,需要考虑是否要进行内存的扩容,使用swap是相当影响性能的。

清理内存碎片

低于4.0-RC3版本的Redis

Redis 4.0-RC3之前的版本并没有内置的内存碎片整理工具。如果你想要清理内存碎片,可以通过重启的方式。

当Redis重新启动时,它会通过RDB持久化功能将数据存储到磁盘,然后再从磁盘加载数据到内存,这个过程可以有效地清理内存碎片。但这种方法会导致服务的临时中断。

高于4.0-RC3版本的Redis

Redis4.0-RC3版本开始,引入了active-defrag 特性。可以在不重启的情况下,自动进行碎片清理。

开启配置如下,此选项的默认值是关闭的,激活碎片整理可能会占据一些 CPU 时间。

redis> config set activedefrag yes 

注意:自动清理内存碎片的功能需要该Redis的内存分配器是jemalloc时才能启用

启用后需要同时满足下面2个参数的设置条件时才会触发自动清理

active-defrag-ignore-bytes 100mb    # 默认100MB,表示内存碎片空间达到100MB时
active-defrag-threshold-lower 10    # 默认10,表示内存碎片空间占OS分配给redis的物理内存空间的比例达到10%时

redis是单进程模型,内存碎片自动清理是通过主线程操作的,也会消耗一定的CPU资源。为了避免自动清理降低Redis的处理性能,如下两个参数可以控制清理动作消耗的CPU时间比例的上下限:

active-defrag-cycle-min 5  # 默认5,表示自动清理过程所用 CPU 时间的比例不低于5%,保证清理能正常开展;
active-defrag-cycle-max 75 # 默认75,表示自动清理过程所用 CPU 时间的比例不高于 75%,一旦超过,就停止清理,从而避免在清理时,大量的内存拷贝阻塞 Redis,导致响应延迟升高。

如果你对自动清理的效果不满意,可以使用如下命令,直接进行手动碎片清理:

redis > memory purge

需要注意的是,该命令会阻塞主进程,并且目前也仅实现了jemalloc作为内存分配器的内存统计,对其他分配器暂不支持。

本篇文章到这就结束了。在我们深入研究Redis内存碎片管理和优化策略后,可以明确一点:理解并合理处理内存碎片化对于保证Redis的性能及稳定性至关重要。

不论是进行内存分配策略的调整,还是使用适当的数据结构,都是对Redis内存管理的优化。

同时,定期的监控和审视也是必不可少的步骤。希望本文能为你在处理Redis内存碎片问题上提供一些有价值的启示。记住,每一个优秀的工程师都应该以理解其使用的工具为荣。让我们持续关注和优化Redis,使其更好地服务于我们的项目,推动业务的发展。


感谢阅读,如果本篇文章有任何错误和建议,欢迎给我留言指正。

老铁们,关注我的微信公众号「Java 随想录」,专注分享Java技术干货,文章持续更新,可以关注公众号第一时间阅读。

热门相关:藏娇记事   魔神狂后   重生成偏执霍少的小仙女   上将大叔,狼来了!   一等狂妃:邪王,请接招!