删除键后内存为什么不立刻降
删除键之后内存不立刻回落是常见现象，原因主要有三类：分配器保留空闲页以备复用而不归还操作系统、异步释放（UNLINK 或 lazyfree 系列）在后台线程慢慢回收、碎片导致的空间需要重新利用。判断要看趋势，而不是某一个瞬间的数值。
基本信息
| 分配器行为 | 空闲页保留在进程内，供后续分配复用 |
|---|---|
| 异步释放 | UNLINK 与 lazyfree 开关把释放交给后台线程 |
| 碎片因素 | 碎片率高时内存回落更慢 |
| 观测口径 | used_memory 与 used_memory_rss 两条曲线一起看 |
| 加速手段 | MEMORY PURGE 请求归还空闲页（jemalloc 有效） |
典型使用场景
- 批量删除后评估：确认回落节奏是否符合机制预期
- 内存告警处理：区分是真泄漏还是分配器保留
- 碎片治理：碎片率高时回落慢，考虑整理或滚动重启
- 容量规划：按常驻内存判断实例真实占用
- 故障复盘：核对删除操作与内存曲线的时间关系
- 压测验证：删除后持续观察趋势，避免被瞬时值误导
观测与动作
观测与动作
redis-cli INFO memory | grep -E 'used_memory:|used_memory_rss|mem_fragmentation_ratio' # 三条曲线一起看
redis-cli MEMORY DOCTOR # 体检结论与建议
redis-cli MEMORY PURGE # 请求归还空闲页（jemalloc）
redis-cli UNLINK big:key # 异步删除大键，键空间立刻摘除
redis-cli CONFIG GET lazyfree-lazy-user-del # 让 DEL 也走异步释放
redis-cli MEMORY STATS # 看分配器与保留相关的细节现象与机制
| 现象 | 原因 | 处理 |
|---|---|---|
| used_memory 降、rss 不降 | 分配器保留空闲页 | 可尝试 MEMORY PURGE |
| 两条曲线都降但明显延迟 | 异步释放进行中 | 观察趋势即可，无需干预 |
| 碎片率长期偏高 | 分配模式或大键导致 | 整理或调整数据形态 |
| 内存持续上涨不回落 | 泄漏或数据真实增长 | 按 Key 分布逐步排查 |
分配器保留空闲页是性能取舍而不是缺陷：把内存页还给系统意味着下次分配要重新申请，成本体现在延迟上。
长期不回落并且伴随缓慢上涨才是危险信号：前者是机制，后者可能指向真实的泄漏或数据增长。