Redis内存过载时jemalloc拒绝分配，是因内部碎片或保留页不足主动返回NULL触发OOM error，与Linux OOM Killer无关；关键看INFO memory中allocator_allocated、active、mapped的剪刀差而非used_memory。
Redis内存过载时，jemalloc 为什么突然拒绝分配？
Redis默认用 jemalloc 管理内存，不是系统 malloc。当内存接近 maxmemory 且淘汰策略未及时生效时，jemalloc 可能因内部碎片或保留页不足而返回 NULL，触发 Redis 的 OOM error —— 这和 Linux OOM Killer 无关，是分配器主动失败。
常见错误现象：OOM command not allowed when used memory > 'maxmemory'，但 INFO memory 显示 used_memory 比 maxmemory 小几百 MB；或者日志里反复出现 Failed to allocate X bytes。
- 检查实际分配压力：用
INFO memory对比used_memory和mem_allocator_stats（需 Redis 7.0+）里的allocated、active、mapped -
jemalloc的dirty页面不会立刻归还 OS，active高但mapped更高，说明有大量“脏但未释放”的页 - 避免在高写入+LRU淘汰场景下用
allkeys-lru：它需要遍历键空间，期间新分配可能卡在jemalloc内部锁上
maxmemory-policy 设置不当会放大 jemalloc 分配失败
淘汰策略不只是“删什么”，它直接影响内存回收节奏和 jemalloc 的腾挪窗口。比如 noeviction 下，哪怕只差 1KB，SET 也会直接报错；而 volatile-lfu 在 key 过期集中时，可能批量释放导致 jemalloc 短暂无法合并空闲块。
- 优先选
volatile-lru或volatile-lfu（如果业务 key 都带 TTL），避免全量扫描开销 - 慎用
allkeys-random：随机驱逐不解决内存碎片，反而让jemalloc的空闲块更零散 - 如果必须用
noeviction，请确保客户端有重试+降级逻辑，而不是依赖 Redis 自动兜底
如何从 INFO memory 判断是不是 jemalloc 自身瓶颈？
关键不是看 used_memory，而是看三组数字的剪刀差：used_memory vs allocator_allocated vs allocator_active。如果 allocator_allocated - used_memory > 500MB，说明 Redis 内部对象已释放，但 jemalloc 没归还；如果 allocator_active - allocator_allocated > 200MB，说明 jemalloc 持有大量“已分配但未使用”的页 —— 这正是过载时分配失败的温床。
- 运行
MEMORY MALLOC-STATS（Redis 6.0+）看arenas数量和每个 arena 的huge、large块分布 - 频繁出现
huge块分配失败？说明大对象（如大SET、HASH）导致jemalloc难以找到连续虚拟地址空间 - 升级到 Redis 7.0+ 并启用
jemalloc的background_thread（通过jemalloc_bg_thread配置），能缓解 dirty page 积压
替换 glibc malloc 能解决问题吗？
不能，而且通常更糟。glibc 的 malloc 在多线程高并发下更容易产生锁竞争，且没有 jemalloc 的 arena 隔离机制，单个慢分配可能拖垮整个实例。Redis 官方只测试并优化了 jemalloc 行为，用 malloc 编译的版本在内存压力下崩溃概率更高。
- 不要改
USE_JEMALLOC编译选项，除非你完整压测过malloc在你 workload 下的fragmentation_ratio和分配延迟 P99 - 真正有效的调优在运行时：调低
jemalloc的lg_chunk（减小 chunk 大小，降低大块浪费），但需重新编译 Redis - 最务实的做法：把
maxmemory设为物理内存的 75%～80%，留出空间给jemalloc的元数据和 OS 缓存，别卡着上限跑
内存分配器不报错，不代表它没在挣扎；used_memory 没超限，也不代表 jemalloc 还有余力。真正难调的是那几 MB 的 invisible overhead —— 它藏在 arena 统计里，不在监控图表上。
