求助：TiDB 集群看不到等待事件，节点又多，该用什么指标判断性能瓶颈？

🪐 TiDB 技术问题 部署&运维管理
,
1

以前做 Oracle、MySQL 单机库的时候，判断瓶颈很直接：CPU 跑满、内存打满、IO wait 飙升、等待事件扎堆，基本就能确认数据库到瓶颈了。但迁到 TiDB 分布式架构之后，发现这套老方法论有点失灵了，主要卡在两个点：

  1. 单节点指标很容易“谎报军情”：某台 TiDB 的 CPU 飙到 70%+，可能只是运维手工跑了个统计查询，集群整体其实还远没到瓶颈；反过来，所有节点 CPU 都很低，业务侧却可能已经出现明显延迟。
  2. 组件太多，很难全局判断：TiDB、TiKV、PD 各有一套指标，Grafana 面板密密麻麻，日常巡检到底该盯哪几个，才能一眼看出“集群整体是不是真到了瓶颈”？

想请教大家三个问题

  1. 日常判断集群是否存在性能瓶颈，你们最核心看哪些指标？
  2. 哪些指标你们会配成核心告警？（除了节点宕机、磁盘满这种硬件级告警，性能瓶颈类的告警大家一般怎么配？单节点 CPU / 内存使用率还会作为核心告警吗？）
  3. 告警阈值是统一标准，还是按集群业务属性单独调？

感谢各位前辈指点！期待实战经验分享，一起提升 TiDB 集群的“健康感知力” :muscle:

2

https://docs.pingcap.com/zh/tidb/stable/grafana-performance-overview-dashboard/
https://docs.pingcap.com/zh/tidb/stable/performance-tuning-methods/

3
  1. 核心指标：盯TiKV的Raft IO、gRPC延迟、Coprocessor耗时，以及TiDB的SQL执行时间、慢查询数、Connection Count。PD的Leader分布、Region健康度（Pending/Incomplete Region）也是关键。单节点CPU/内存只作参考，别当瓶颈判断依据。
4

核心三指标：Duration（P99/avg）、TiKV coprocessor 耗时、Coprocessor CPU。运维告警重点配 TiDB 的 connection count、TiKV store size/region count、PD scheduler 积压。单节点 CPU 高不 panic，关键看整体 QPS+延迟是否同时恶化。

6

慢查询日志 或 Top SQL 找元凶 , TiDB Dashboard 的概况页

7


kang

3 天

  1. 核心指标：盯TiKV的Raft IO、gRPC延迟、Coprocessor耗时，以及TiDB的SQL执行时间、慢查询数、Connection Count。PD的Leader分布、Region健康度（Pending/Incomplete Region）也是关键。单节点CPU/内存只作参考，别当瓶颈判断依据。
8
  • TiDB Server = 计算层（无状态）：单节点 CPU 高只是单条大 SQL、临时统计任务，流量可被代理打散，单个 TiDB CPU 永远不作为集群瓶颈判定依据；全集群所有 TiDB 整体 CPU 水位才有参考价值。
  • TiKV = 存储 + 计算底座（真实瓶颈绝大多数在这里）：业务慢、事务延迟、写入卡顿 90% 根因在 TiKV，TiDB 只是背锅显示 SQL 耗时上涨。
  • 单机 IOwait、系统 CPU% 在分布式下无意义：TiKV 内部 Raft 同步、coprocessor、后台 compaction、GC 大量后台线程占用 CPU/IO，单纯系统指标分不清是业务流量还是后台任务。
  • 等待事件被分布式拆分：TiDB 等待分散在「TiDB 会话等待、TiKV raft 等待、MVCC 等待、网络等待、Region 调度排队」多处，没有 Oracle 那种统一的等待视图。
1 个赞