Redis怎样监控哨兵自身的资源消耗_利用系统工具排查Sentinel进程的CPU与内存占用

查哨兵进程资源需用ps和top实时监控cpu与内存，关注rss突增、%cpu峰值及线性上涨；结合日志分析+sdown/+odown频次、info sentinel状态（如sentinel_tilt、sentinel_running_scripts）定位真实压力源。

查哨兵进程的 CPU 和内存：用 ps 和 top 最直接

redis 哨兵（redis-sentinel）是独立进程，不处理业务请求，但监控、选举、通信全靠它自己跑。它的资源消耗虽比 Redis 实例低，但若部署多个哨兵又没做资源限制，CPU 毛刺或内存缓慢增长可能被忽略，直到故障转移时响应变慢甚至卡住。

最轻量、最实时的方式就是用系统命令盯住它：

• ps aux | grep redis-sentinel：一眼看出每个哨兵进程的 %CPU 和 %MEM，注意看 VSZ（虚拟内存）和 RSS（常驻物理内存），RSS 突增往往意味着连接数暴增或配置加载异常
• top -p $(pgrep -f "redis-sentinel")：聚焦哨兵 PID，观察 %CPU 峰值是否持续 >30%，以及 RES（即 RSS）是否随时间线性上涨——后者很可能是内存泄漏信号（比如哨兵反复重连失败却未释放连接上下文）
• 别只看平均值：哨兵在主观下线判定、选举投票、发布配置变更时会短时飙高 CPU，要结合 redis-cli SENTINEL MASTER <master-name></master-name> 的 num-other-sentinels 和 quorum 等字段，判断是否因哨兵数量配置不合理（如 5 个哨兵却设 quorum 4）导致频繁协商加重负担

从哨兵日志里挖真实压力点：关注 INFO、+sdown、+odown 频次

哨兵自身不暴露 INFO 接口给客户端，但它会把关键行为写进自己的日志（默认 sentinel.log）。这些日志不是“有没有报错”，而是“有多忙”。

• 高频 +sdown master xxx 日志？说明哨兵频繁认为主节点失联——可能网络抖动、主节点 GC STW 时间长、或 down-after-milliseconds 设得太小（如低于 3000ms）；这会让哨兵反复发起 SENTINEL is-master-down-by-addr 查询，白白耗 CPU
• 大量 +odown master xxx #quorum/3？代表客观下线判定频繁触发，但最终没走故障转移——说明哨兵集群协调成本高，尤其当哨兵跨机房部署且网络延迟不稳时，心跳包丢失率上升直接拉高协商开销
• 日志里出现 Failed to resolve hostname 或 Connection refused 连从节点？哨兵会不断重试，每秒重连一次，积少成多也会吃掉可观 CPU，应检查 sentinel monitor 配置里的 IP 是否写死为已下线的旧地址

用 redis-cli 看哨兵内部状态：SENTINEL INFO 是唯一“自述”入口

哨兵提供 INFO SENTINEL 命令（注意不是 INFO），返回的是它自己运行时的状态快照，比系统命令更贴近语义层。

• sentinel_masters:1 —— 正常；若为 0，说明哨兵压根没加载到任何监控配置，检查 sentinel.conf 中 sentinel monitor 行是否被注释或路径错误
• sentinel_tilt:0 —— 必须为 0；若为 1，表示哨兵进入“倾斜模式”（Tilt Mode），因系统时钟跳变或自身事件循环严重延迟而暂停所有主观判断，此时它既不投票也不通知，整个高可用形同虚设
• sentinel_running_scripts:0 —— 应始终为 0；若大于 0，说明 notification-script 或 failover-script 执行超时未退出，脚本卡住会阻塞哨兵主循环，必须立刻 kill 对应子进程并检查脚本逻辑
• 执行 redis-cli -p 26379 INFO SENTINEL 时如果响应极慢（>1s），大概率是哨兵正忙于同步配置或重连下游节点，不是命令本身问题，而是负载真实存在

避免常见误判：哨兵 RSS 高 ≠ 有 bug

看到哨兵 RSS 达到 80MB 就慌？先别急着调优。哨兵内存增长主要来自三块，其中两块完全合理：

• 连接缓冲区：每个被监控的 Redis 节点（主 + 从 + 其他哨兵）都维持至少一个 TCP 连接，每个连接默认缓冲区约 1–2MB；10 个节点 × 2MB ≈ 20MB，纯属正常开销
• 拓扑缓存：哨兵会缓存所有节点的 INFO 输出（尤其是 replication 和 sentinel 段），节点越多、INFO 返回越长，这部分内存就越大；这是为了减少重复查询，不是泄漏
• 真正该警惕的是 RSS 持续增长且不回落：比如每小时涨 5MB，连续 12 小时——这时要抓 gcore 快照用 gdb 分析堆，或启用 redis-sentinel --loglevel verbose 看是否有异常循环日志

哨兵的资源模型很简单：它不存数据、不解析命令、不处理业务逻辑，所有开销都源于“观察”和“协调”。盯住连接数、日志频次、INFO SENTINEL 里的 tilt 和脚本计数，比盲目调 maxmemory 有用得多。