如何通过开启监控和堆栈工具定位查大Key引发的OOM问题？

本文共计1122个文字，预计阅读时间需要5分钟。

使用 `redis-cli --bigkeys` 命令可以统计每个 key 的序列化后字节数，不包括 Redis 内部数据结构（如 dictEntry、sds、指针等）。实际内存占用通常比显示的高 30% 到 100%。对于 `hash` 或 `zset` 类型，元素越多，额外开销越明显。

它也不区分 key 是否带过期时间（EXPIRE）、是否被频繁访问（影响 LRU/LFU 淘汰权重），更不会告诉你该 key 是否正在被客户端缓冲区大量读取（比如 CLIENT LIST 中 obuf 高的连接可能正卡在读一个大 list）。

• 线上紧急排查时，优先用它快速筛出 top N 大 key，但别把它当唯一依据
• 若扫描结果里没发现明显大 key，但 used_memory 持续飙升，重点看 mem_fragmentation_ratio 和 client_longest_output_list
• 它不阻塞服务，但会遍历全库 —— 在高 QPS 实例上慎用，建议在低峰期执行

离线分析 RDB 文件时，-bytes 参数设多少才合理？

设 -bytes 1024 是常见起点，但实际要结合业务 value 分布来调。比如你业务中正常 string key 值基本在 500B 左右，那设 1024 就能覆盖异常；但如果普遍存 JSON，平均 8KB，再设 1024 就会刷出太多噪音。