Redis本地复现OOM错误失败，求排查操作问题

嘿，我之前也踩过这个坑，咱们来一步步拆解你遇到的问题：

核心原因：OOM报错只在写入新数据时触发 #

你设置的maxmemory_policy:noeviction策略逻辑是：当Redis使用内存超过maxmemory后，拒绝所有会增加内存的写入操作，但不会主动触发报错——只有当你尝试执行新的写入（比如新增键、给列表追加元素等）时，才会抛出OOM command not allowed when used memory > 'maxmemory'错误。

你现在看到used_memory_human维持在10.01M左右，这只是Redis当前已使用的内存（包括内部结构的额外开销），但如果没有新的写入操作，Redis不会主动报错。

你可能的操作误区 #

• 修改已有键而非新增：如果你只是在更新已存在的键值（比如SET existing_key new_value），内存可能不会明显增加，自然不会触发OOM检查。
• 测试数据的粒度太小：如果每次写入的内容很小，Redis的内存统计可能有细微延迟，或者内部结构的开销占比不明显，导致你没察觉到需要触发OOM的临界点。

正确的复现步骤 #

试试这个方法，保证能触发报错：

1. 先清空当前数据库，避免已有数据干扰：

   redis-cli FLUSHDB
   

2. 批量写入大体积的键值对，比如每个值是1MB的字符串：

   # 循环写入10个1MB的键，总内存约10MB
   for i in {1..10}; do redis-cli SET "key$i" "$(printf 'a%.0s' {1..1048576})"; done
   

3. 此时查看内存使用，应该接近或刚超过10M：

   redis-cli info memory | grep used_memory_human
   

4. 尝试写入第11个键，这时候就会触发OOM报错：

   redis-cli SET "key11" "$(printf 'a%.0s' {1..1048576})"
   

额外说明 #

为什么used_memory_human会超过10M？因为Redis的used_memory统计包含了内部数据结构（比如哈希表、字典节点）的内存开销，这些是无法避免的额外消耗。但maxmemory的限制逻辑是：当新写入操作会导致内存超过阈值时，就会触发拒绝策略——所以即使当前内存已经略超，只要你不执行新的写入，就不会报错。

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