Redis重启后内存减少2GB的原因及内存缓存相关疑问

嘿，我来帮你把这个问题掰扯清楚～

那2GB内存消失的核心原因 #

这2GB其实就是Redis进程之前占用但没还给操作系统的空闲内存块，根源在于Redis依赖的内存分配器（比如jemalloc、libc malloc）的特性：

• 当你删除Redis里的键时，Redis只会把对应内存标记为内部可用，但分配器不会立刻把内存还给操作系统。这是因为被删除的键往往和现存的键位于同一个内存页里，分配器没法单独释放一页中的部分内存，只能保留整个内存页。
• 所以在重启前，你的Redis进程RSS（实际占用物理内存）是29.5GB，但Redis自己统计的用户实际使用内存是27.5GB，多出来的2GB就是分配器持有的、已经被Redis标记为空闲但没还给OS的内存块。
• 当你重启Redis时，旧的进程退出，操作系统会回收该进程占用的所有内存，包括这些空闲内存块；新启动的Redis进程只需要加载当前实际使用的27.5GB数据，所以RSS直接降到了27.5GB。

关于“缓存空闲内存”的疑问 #

这2GB不是什么“缓存的缓存”，就是我上面说的分配器层面的空闲内存：

• Redis本身是纯内存数据库，它直接管理内存用于存储键值对，没有额外的“缓存”层。
• 这部分空闲内存是Redis已经用不上的，但分配器为了后续新键值对的分配效率，暂时保留下来复用——比如之后你新增数据时，分配器会优先用这些空闲内存，而不是向OS申请新内存，所以重启前即使写入新数据，RSS也不会继续增长。

额外提醒：内存碎片率的误区 #

当你的Redis里大量键被删除后，会出现used_memory（Redis统计的用户内存）很低但RSS很高的情况，这时候计算的内存碎片率（used_memory / RSS）会偏高，这个指标就失去参考意义了——因为不是真的内存碎片多，而是分配器持有大量空闲内存没释放。重启后，RSS和used_memory会回到接近的状态，碎片率也会恢复正常。

内容的提问来源于stack exchange，提问作者nhaht