前言
作为面试经历都很丰富的兄弟们,应该或多或少被问到或者自己亲身经历过这个问题,问题如下:
👉 Redis做了数据删除操作,为什么使用top命令时,还是显示Redis占了很多内存?
没做相关功课的人觉得这个问题有问题,删了数据还说占着内存,面试官不是在误导我吗,事实并非如此!
这里先说答案 📝📝
🌐 实际上,这是因为,当数据删除后,Redis 释放的内存空间会由内存分配器管理,并不会立即返回给操作系统。所以,操作系统仍然会记录着给 Redis 分配了大量内存。
而 used_memory_rss 记录着在操作系统角度,Redis进程占用的物理总内存
这样看来文章好像讲完了,开头就知道答案,当然不是,内容多着呢~
文章将从下面这些点分析扩展你对于Redis内存方面的知识点,以及内存碎片和如何清理内存碎片。
毕竟面试官问你一个问题,你选择只回答一句和面试官掰扯掰扯两种方式,那么第二种情况更会让他觉得你厉害爆了,懂得真多!🤣🤣🤣
Redis内存消耗组成
Redis内存消耗主要在于其主进程消耗和子进程消耗。而主进程消耗又主要包括自身内存、对象内存、缓冲区内存、内存碎片四个方面:
自身进程占用内存
Redis进程自身所占用的内存,这部分内存通常很小,一个空的Redis进程所消耗的内存几乎可以忽略不计
数据对象内存
对象占用的内存是Redis中占用内存最大的,这里存储这我们的键值对,我们知道不同的数据类型占用的内存空间大小也不同,特别是那种大key占用内存的情况就更惊人了。
缓冲区
Redis主要有三大缓冲区:客户端缓冲区、AOF缓冲区、复制缓存区
📔 客户端缓冲区: 为了解决客户端和服务端请求和处理速度不匹配问题(即CPU 与 I/O 设备速度不匹配的矛盾),分为输入和输出缓冲区。
输入缓冲区会先把客户端发送过来的命令暂存起来,Redis 主线程再从输入缓冲区中读取命令,进行处理。当在处理完数据后,会把结果写入到输出缓冲区,再通过输出缓冲区返回给客户端。
📘 AOF缓冲区: 在进行AOF持久化时所用到的缓冲区,AOF缓冲区消耗的内存取决于AOF重写时间和写入命令量, 分为AOF缓冲区和AOF重写缓冲区
📙 复制缓冲区:是在集群环境中为了保证主从节点数据同步的所设置的,由于主从节点间的数据复制包括全量复制和增量复制两种。因此复制缓冲区也分为复制缓冲区和复制积压缓冲区两种,分别用于全量和增量同步
内存碎片
内存碎片主要是有两个原因:操作系统的内存分配机制、Redis存储特性,这两个原因我们在文章中会具体提到。
子进程消耗
子进程消耗是指在RDB、AOF重写时fork()子进程的内存消耗
🔥🔥 有人说这不是用到了写时复制技术吗?
📢 虽然子进程可以不用完全复制父进程的物理内存,但是仍然需要复制其内存页表,在此期间如果有写入操作则需要复制出一份副本出来,因此同样会消耗一部分内存,消耗的内存两取决于RDB和AOF重写期间的写入命令数量。
查看内存指标
查看当前Redis相关内存信息用 info memory 命令,如果是集群使用 cluster info命令
127.0.0.1:6379> info memory
# Memory
used_memory:856472 // Redis 存储数据占用的内存量
used_memory_human:836.40K // 人类可读形式返回内存总量
used_memory_rss:1282048 // 操作系统角度,进程占用的物理总内存
used_memory_rss_human:1.22M // used_memory_rss 可读性模式展示
used_memory_peak:857448 // 内存使用的最大值,表示 used_memory 的峰值
used_memory_peak_human:837.35K // 以可读的格式返回 used_memory_peak的值
used_memory_lua:37888 // Lua 引擎所消耗的内存大小。
used_memory_lua_human:37.00K
maxmemory:2147483648 // 能使用的最大内存值,字节为单位。
maxmemory_human:2.00G // 可读形式
maxmemory_policy:noeviction // 内存淘汰策略
// used_memory_rss / used_memory 的比值,代表内存碎片率
mem_fragmentation_ratio:2.79
used_memory_rss:操作系统分配给 Redis 进程的内存空间(包含内存碎片占用的空间),此数据结果约等于top、ps命令看到的数据结果,是从操作系统层看到的数据
maxmemory:Redis 最大可用内存,0表示不限制,我们一般会设置这个值,避免所有内存超过物理内存
内存为何没释放
Redis 释放的内存空间会由内存分配器管理,并不会立即返回给操作系统,是因为采用了一种称为“惰性删除”的机制,即在数据被删除之后,并不会立即释放内存空间,而是等到有新数据需要使用该空间时才会释放。
这种方式的好处是可以减少内存分配和释放的开销,提高 Redis 的性能。
但是Redis释放内存空间可能不是连续的,可能导致空间闲置(也就是出现内存碎片),而内存碎片过大会导致明明有空间可用,但是却无法存储数据!
ok!我们继续看看什么是内存碎片
内存碎片
前面我们已经了解了Redis占用内存的组成以及如何查看内存占用信息,接下来看什么是内存碎片和导致出现内存碎片的原因。
Redis使用多种内存分配策略,例如 jemalloc 和 libc,这些分配器无法做到按需分配,通常会按照固定大小进行分配。例如,如果Redis申请6字节的内存,操作系统会分配8字节的内存给Redis使用,剩下的2个字节空间无法被使用就是内存碎片。
但这种分配方式也有优势,可以减少向操作系统申请空间分配。
导致Redis产生内存碎片主要由以下两点:
-
• 内存分配机制导致
-
• 数据修改引发空间扩容和释放
内存分配机制导致
操作系统的架构和 Redis jemalloc 分配策略无法做到按需分配,而是应用程序申请内存大小必须是一块连续的内存地址空间。
这种连续是按固定大小来分配的,比如:8字节、16 字节、32 字节、64 字节 ... 这种方式会在程序申请内存接近某个值的时候,jemalloc就会给它分配响应大小的内存空间。
上图中:
第一次存储数据是需要6字节,而Redis内存分配策略给你分配了8字节,空出2个字节的空间。
第二次存储数据是需要4个字节,但是空出的2个字节无法保存4字节数据,所以会再次向系统申请8字节内存空间,空出了4字节,两次存储数据就多出来6个字节的内存碎片。
这也就是内存分配机制导致的形成碎片的风险和原因。
数据修改引发空间扩容和释放
这个原因应该更好理解吧,若修改数据时占用的空间有变化,此时就需要扩容或者缩容;而删除数据也会将内存释放出来,形成碎片。
如下图:
-
• 各数据占用内存字节空间分别是A:2、B:1、C:3、D:3
-
• 此时D释放了一个字节空间
-
• A修改了数据,增加了一个字节。为保证A的内存空间连续性,B的数据拷贝到了第二阶段D释放出来的那个字节位置
-
• C修改后删除了2个字节空间
可以看出经过一系列对数据的修改,C和D之间有2字段内存空间,此时多出来2字节空间就是内存碎片。
处理内存碎片
如何在进行处理内存碎片,那么以什么为参考呢?
前面说的 info memory命令,如果指标值 mem_fragmentation_ratio (内存碎片率)的值,在 1 < 碎片率 < 1.5,可以认为是合理的,而大于 1.5 说明碎片已经超过 50%,我们需要采取一些手段解决碎片率过大的问题。
有下面三种方式可处理 🚩🚩🚩:
重启Redis实例
重启Redis属于直接当时粗暴的方式,在重启之前要考虑两点:
-
• 若Redis的数据没有持久化,数据会丢失
-
• 即使做了持久化,重启需要通过AOF或RDB恢复数据,恢复时间取决于日志的大小,如果恢复时间长,这个阶段实例就不能提供服务了
这种方式还是要慎重!
memory purge手动碎片整理
手动整理内存碎片,会阻塞主进程,生产环境慎用。
memory purge 和 activedefrag回收的并不是同一块区域的内存,它简单粗暴的尝试清除脏页以便内存分配器回收。可以根据实际情况和activedefrag配合使用,memory purge在极端情况下效果较好,activedefrag则更彻底。
开启activedefrag自动碎片整理
在Redis 4.0 版本后新增配置项activedefrag,activedefrag默认关闭,计划清理碎片时需手动开启,命令如下:
127.0.0.1:6379> config set activedefrag yes
自动整理内存碎片,其原理是通过scan迭代整个Redis数据,通过一系列的内存复制、转移操作完成内存碎片整理,由于此操作使用的是主线程,故会影响Redis对其他请求的响应。
如上图碎片整理过程:
-
1. 清理前,C和D之间多了2字节的内存碎片
-
2. 清理过程:将B和D的数据分别拷贝到C和D之间的闲置空间,这样2个字节的闲置空间就形成了连续空间。当新应用要申请小于3个字节的空间时,这个闲置空间就能利用起来了
清理的条件
active-defrag-ignore-bytes 200mb:内存碎片占用的内存达到 200MB,开始清理;
active-defrag-threshold-lower 20:内存碎片的空间占比超过系统分配给 Redis 空间的 20% ,开始清理