应重点监控info memory中mem_fragmentation_ratio（>1.5需干预）、used_memory_rss与used_memory差值（>500MB需开启碎片整理），并结合evicted_keys、rejected_connections等被动指标判断真实瓶颈。
直接看 info 的关键 section，比开监控平台更快定位真实瓶颈——但必须知道每个字段代表什么、哪些值一过阈值就该立刻干预。
怎么看 info memory 判断内存是否真成瓶颈
很多人只扫一眼 used_memory 就下结论，其实真正危险的是 mem_fragmentation_ratio 和 used_memory_rss 的组合。比如 used_memory 是 2GB，used_memory_rss 却飙到 5GB，mem_fragmentation_ratio > 1.5，说明内存碎片严重，不是容量不够，而是分配器卡住了。
-
used_memory_human是实际数据占用，不包括碎片和元数据 -
mem_allocator是当前内存分配器（如 jemalloc），不同版本行为差异大 -
evicted_keys> 0 表示已触发驱逐，但未必是 LRU 满了——也可能是maxmemory-policy配错成noeviction导致 OOM kill - 如果
mem_clients_normal或mem_clients_slaves异常高，说明客户端缓冲区堆积（常见于大 value + 高频订阅）
用 info stats 抓住吞吐与延迟异常源头
instantaneous_ops_per_sec 是瞬时 QPS，但它会掩盖毛刺；更关键的是 rejected_connections、expired_keys、evicted_keys 这三个“被动动作”计数器——它们一上涨，基本等于 Redis 在求救。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
total_commands_processed/uptime_in_seconds可粗略算平均 QPS，但不如instantaneous_ops_per_sec灵敏 -
slowlog_len> 0 时，必须立刻查slowlog get，别等告警 -
keyspace_hits和keyspace_misses算出命中率，used_memory 持续涨，大概率是缓存穿透或 key 设计不合理 -
pubsub_channels和pubsub_patterns突增，可能引发 client-output-buffer-limit 超限，导致连接被踢
为什么 info cpu 里的 used_cpu_sys 比 used_cpu_user 高得多
这通常不是 Redis 自身逻辑耗 CPU，而是系统级开销压倒了它。比如：used_cpu_sys 长期 > used_cpu_user × 2，大概率是内核在疯狂做页回收（memory section 里 mem_fragmentation_ratio 高会加剧这个现象），或者开启了 transparent_hugepage 导致 THP 扫描阻塞主线程。
- Redis 是单线程处理命令，
used_cpu_user高才说明命令本身复杂（如sort、hgetall大 hash） -
used_cpu_sys高 +latency doctor提示 “fork” 延迟，基本锁定是 RDB/AOF fork 子进程时，内存脏页太多导致 copy-on-write 卡顿 - 检查
/sys/kernel/mm/transparent_hugepage/enabled，生产环境必须设为never
info clients 里哪些连接状态最值得盯
connected_clients 数字本身没意义，要看它的构成：client_longest_output_list > 1000 或 client_biggest_input_buf > 1MB，说明某个客户端正在拖慢整个事件循环。
-
blocked_clients> 0 且持续不降？立刻client list查谁在brpop、blpop或wait，并确认 timeout 是否合理 -
tracking_clients非 0 时，注意total_blocked_clients是否同步上升——客户端 tracking table 溢出会导致命令延迟突增 -
client_recent_max_input_buffer和client_recent_max_output_buffer是近期峰值，比当前值更有预警价值 - 如果
connected_clients接近maxclients，别急着调大——先看是不是连接泄漏（应用没 close、连接池配置错误）
真正容易被忽略的，是把 info 当静态快照看。它每秒都在变，而很多关键指标（比如 instantaneous_input_kbps、instantaneous_output_kbps）只有连续采样才能看出趋势。手动敲 redis-cli info stats 五次不如写一行 watch -n 1 'redis-cli info stats | grep -E "instantaneous|rejected|evicted"' ——瓶颈从来不在某一个数字，而在数字变化的节奏里。
