Redis没有配置maxmemory时会自动淘汰吗_剖析64位系统默认无限制可能导致OS强杀进程-Redis-PHP中文网

redis不设maxmemory时不会触发淘汰机制，因默认策略noeviction且不启动任何淘汰逻辑，内存持续增长直至oom killer强杀进程。

redis没有配置maxmemory时会自动淘汰吗_剖析64位系统默认无限制可能导致os强杀进程

不会。Redis在未配置maxmemory时，**默认策略是noeviction，且不启动任何内存淘汰逻辑**——它既不会主动删key，也不会因内存增长而自动释放空间。此时Redis会持续申请内存，直到操作系统OOM Killer介入并强杀进程，这是生产环境最典型的“静默崩溃”源头之一。

64位系统下，Redis进程可申请的虚拟内存近乎无限（受限于系统总内存和swap），但物理内存耗尽后，Linux内核会根据vm.oom_kill_score_adj选择进程kill，Redis常因RSS高被优先干掉
INFO memory中used_memory持续上涨、mem_allocator无异常，但evicted_keys始终为0，就是没启用淘汰的铁证
哪怕你配了maxmemory-policy volatile-lru，只要没设maxmemory，这条策略完全不生效

Redis设计上把内存上限视为“业务契约”，而非运行时自适应参数。没有maxmemory，就等于告诉Redis：“你爱用多少用多少”，而它真会照做——尤其在缓存场景下，一个SET bigdata "..."可能瞬间吃掉数GB内存。

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

默认不设maxmemory ≠ 安全，默认是“放任”，不是“智能”
容器环境（如Docker）中若只限制cgroup memory，但Redis内部无maxmemory，会导致Redis在OOM前仍不断触发内存分配失败（malloc返回NULL），引发不可预测的断连或命令拒绝
某些云托管Redis服务（如阿里云Tair、腾讯云CKV）会强制要求设置maxmemory，否则拒绝创建实例

别直接填free -h里显示的“available”，要按Redis进程实际RSS（Resident Set Size）预留余量。因为Redis的内存使用包含碎片、元数据、AOF缓冲、复制积压缓冲等隐藏开销，通常比used_memory高15%–30%。

用ps -o pid,rss,comm -C redis-server查当前RSS，再加20%作为maxmemory目标值（例如RSS=3.2GB → 设maxmemory 4gb）
若启用了RDB/AOF，额外预留512MB以上给持久化子进程的copy-on-write内存
禁止设成maxmemory 90% of total RAM这类模糊表达——Redis不识别百分比，只认字节单位（2gb、1024mb、512000000）

即使正确设置了maxmemory和maxmemory-policy，淘汰也可能静默失效。常见卡点不在策略本身，而在内存统计与触发时机。

淘汰只在**写命令执行过程中**检测内存超限（如SET、LPUSH），读命令（GET、HGETALL）不会触发；所以单纯dump数据看不出淘汰行为
INFO stats中evicted_keys为0，但used_memory_human长期贴近maxmemory，说明淘汰被阻塞——大概率是maxmemory-policy noeviction（拼写错误或配置未重载）
使用allkeys-*策略时，若所有key都带过期时间（EXPIRE），Redis仍按全部key处理；但用volatile-*策略时，**没有过期时间的key完全免疫淘汰**，哪怕内存爆满也岿然不动

Redis的淘汰机制不是后台守护线程，它没有“定期扫描”或“预判式清理”。一切动作都绑在客户端命令的执行路径上，这意味着：压力低时淘汰延迟明显，突发写入可能瞬间冲破阈值导致写失败——这个反应滞后性，是很多容量评估翻车的真正盲区。