共计 3552 个字符,预计需要花费 9 分钟才能阅读完成。
导读 | 如果发现 Redis 存储数据占用的内存比操作系统分配给 Redis 的内存小很多,但是数据无法保存,那么可能是内存碎片很多。使用 info memory命令查看内存碎片 mem_fragmentation_ratio 指标是否正常。 |
我们先来看一个问题, 假设 Redis 实例保存了 5GB 的数据,现在删除了 2GB 的数据,那么 Redis 进程占用的内存会不会减少呢?
答案是:它可能仍然占用大约 5GB 内存,即使 Redis 数据只占用大约 3GB。
如果 maxmemory 不设置该参数,Redis 不会触发内存淘汰策略删除数据。
Redis 会继续为新写入的数据分配内存。分配失败会导致应用程序报错,当然不会导致宕机。
注:设置 maxmemory参数,执行命令 CONFIG SET maxmemory 100mb,或在 redis.conf 配置文件中设置 maxmemory 100mb。
使用 top 命令查看数据是否已经删除,为什么它仍然占用这么多内存?
当我们使用 top 命令查看系统使用情况时,会发现内存依然很高,Redis 并没有真正释放内存。那么内存都去哪儿了?这时候我们就需要使用 info memory 命令获取 Redis 内存相关的指标。
127.0.0.1:6379> info memory
# Memory
used_memory:1132832 // Redis Amount of memory used to store data
used_memory_human:1.08M // Returns the total amount of memory in human readable form
used_memory_rss:2977792 // From the perspective of the operating system, the total physical memory occupied by the process
used_memory_rss_human:2.84M // used_memory_rss Readability mode display
used_memory_peak:1183808 // The maximum value of memory used, representing the peak value of used_memory
used_memory_peak_human:1.13M // Returns the value of used_memory_peak in a human readable format
used_memory_lua:37888 // Lua The amount of memory consumed by the engine。used_memory_lua_human:37.00K
maxmemory:2147483648 // The maximum memory value that can be used, in bytes.
maxmemory_human:2.00G // readable form
maxmemory_policy:noeviction // Memory Retirement Policy
mem_fragmentation_ratio:2.79 // The ratio of used_memory_rss & used_memory represents the memory fragmentation rate
Redis 进程内存消耗主要由以下几部分组成:
Redis 自身的空进程占用的内存很小,可以忽略不计,而对象内存是最大的,里面存放了所有的数据。
需要注意, 如果缓冲区有大流量的场景很容易失控,导致 Redis 内存不稳定。
内存碎片过多导致有可用空间不足,无法存储数据。内存碎片 Fragmentation = used_memory_rss 实际使用的物理内存(RSS 值)除以 used_memory 实际存储的数据内存。
内存碎片会导致内存空间空闲,但无法存储数据。比如你和女朋友去电影院看电影,你们肯定是要在一起的。
假设现在有 8 个座位,已售出 4 张票,还有 4 张可供购买。不过巧合的是,买票的人很奇怪,都是隔一个座位买票。即使还有 4 个座位,也不能买顺序连接两个座位的票。
主要有两个原因:
下面我们就实际发生的原因进行探讨。
Redis 默认的内存分配器使用 jemalloc,可选的分配器有:glibc,tcmalloc。
内存分配器不能按需分配,而是使用固定范围的内存块进行分配。
比如 8 字节、16 字节……、2KB、4KB,当申请内存最接近固定值时,jemalloc 会分配最接近固定值的空间。这样就会出现内存碎片。
比如程序只需要 1.5KB,而内存分配器会分配 2KB 的空间,那么这 0.5KB 就是碎片。这样做的目的是减少内存分配的次数。比如你申请 22 个字节的空间来存放数据,jemalloc 就会分配 32 个字节。如果后面需要写入 10 个字节,则不需要向操作系统申请空间。您可以使用之前请求的 32 个字节。
当一个键被删除时,Redis 不会立即将内存归还给操作系统。发生这种情况是因为底层内存分配器的管理。例如,大多数已删除的键仍与其他有效键分配在同一内存页中。
此外,为了重用空闲内存块,分配器删除了原始 5 GB 数据中的 2 GB。再次向实例添加数据时,Redis 的 RSS 会保持稳定,不会增加太多。因为内存分配器基本上重新使用了之前删除释放的 2GB 内存。
由于内存分配器是按照固定的大小分配内存,因此分配的内存空间通常会大于实际数据占用的大小,这会造成碎片,降低内存的存储效率。
另外,键值对的频繁修改和删除导致内存空间的扩大和释放。例如,如果原来占用 32 个字节的字符串现在修改为占用 20 个字节的字符串,那么释放的 12 个字节就是空闲空间。
如果下一次数据存储请求需要申请一个 13 字节的字符串,刚刚释放的 12 字节空间就不能使用,造成碎片。
分片最大的问题:空间总量足够大,但是这些内存并不连续,可能存不下数据。
mem_fragmentation_ratio = used_memory_rss/ used_memory
首先要判断是否发生了内存碎片,重点看 info memory命令执行后的 mem_fragmentation_ratio 指标,表示内存碎片率。
如果 1
自动清理虽然好,但也不要乱来。操作系统需要消耗资源将数据移动到新的位置,然后释放原来的空间。
Redis 操作数据的指令是单线程的,所以在数据复制和移动时,只有清理碎片后才能处理请求,会造成性能损失。
那么问题来了,如何减少对性能的影响来实现自动清理碎片?
问得好,用下面两个参数来控制内存碎片清理和结束的时机,避免占用过多 CPU,减少清理碎片对 Redis 处理请求的性能影响。
启用自动内存碎片整理:
CONFIG SET activedefrag yes
这只是为了启用自动清洁。当清理需要同时满足以下两个条件时,就会出发清理操作。
active-defrag-ignore-bytes 200mb:内存碎片占用内存达到 200MB,开始清理;
active-defrag-threshold-lower 20: 内存碎片空间超过系统分配给 Redis 空间的 20%,开始清理。
清理时间是有的,需要控制清理对性能的影响。一二设置先分配清理碎片占用的 CPU 资源,保证碎片可以正常清理,避免对 Redis 处理请求造成性能影响。
active-defrag-cycle-min 20:自动碎片整理过程中占用 CPU 时间比例不低于 20%,以保证清理任务正常进行。
active-defrag-cycle-max 50:自动清理进程占用 CPU 时间比例不能高于 50%。如果超过,会立即停止清理,避免阻塞 Redis 造成高延迟。
如果发现 Redis 存储数据占用的内存比操作系统分配给 Redis 的内存小很多,但是数据无法保存,那么可能是内存碎片很多。使用 info memory命令查看内存碎片 mem_fragmentation_ratio 指标是否正常。
然后我们启用自动清理并合理设置清理时间和 CPU 资源占用。该机制涉及内存复制,这对 Redis 性能构成潜在风险。如果 Redis 性能变慢,检查是否是清理碎片导致的。如果是这样,减小配置 active-defrag-cycle-max 的值。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)