查哨兵进程资源需用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 有用得多。
