【TiDB 4.0 PCTA 学习笔记】- 3.7.1 Metrics that DBAs should notice（运维中的关键监控）@2班+邱育珍

☄️ 学习与认证 经验&心得&笔记
,
1

课程名称：3.7.1 Metrics that DBAs should notice（运维中的关键监控）

学习时长：30min

课程收获：

DBA 需要关注的一些和性能相关的 metrics，模块包括 system info、TiDB、TiKV、PD 以及 Dashboard。

课程内容：

对于日常运维，我们单独挑选出重要的 Metrics 放在 Overview 页面，方便日常运维人员观察集群组件 (PD, TiDB, TiKV) 使用状态以及集群使用状态。

以下为 Overview Dashboard 监控说明：

Services Port Status

  • Services Up：各服务在线节点数量

PD

  • etcd

    • 99% WAL fsync duration：99% 的情况下，持久化 WAL 所需花费的时间，这个值通常应该小于 1s，最好是< 5ms
    • 99% Region heartbeat latency：99% 的情况下，心跳的延迟,最好是< 5ms

  • 监控指标介绍

    • PD role：当前 PD 的角色
    • Storage capacity：TiDB 集群总可用数据库空间大小
    • Current storage size：TiDB 集群目前已用数据库空间大小，TiKV 多副本的空间占用也会包含在内
    • Normal stores：处于正常状态的节点数目
    • Abnormal stores：处于异常状态的节点数目，正常情况应当为 0
    • Number of Regions：当前集群的 Region 总量，请注意 Region 数量与副本数无关
    • 99% completed_cmds_duration_seconds：单位时间内，99% 的 pd-server 请求执行时间小于监控曲线的值，一般 <= 5ms
    • Handle_requests_duration_seconds：PD 发送请求的网络耗时
    • Region health：每个 Region 的状态，通常情况下，pending 的 peer 应该少于 100，miss 的 peer 不能一直大于 0
    • Hot write Region’s leader distribution：每个 TiKV 实例上是写入热点的 leader 的数量
    • Hot read Region’s leader distribution：每个 TiKV 实例上是读取热点的 leader 的数量
    • Region heartbeat report：TiKV 向 PD 发送的心跳个数
    • 99% Region heartbeat latency：99% 的情况下，心跳的延迟

TiDB

主要关注点
image

  • Query

    • 时长：99%时延应小于100ms(OLTP)
    • 慢查询：不应有太多慢查询，关注原因
    • Ideal CPS(Command Per Second)：默认不可见参数，通过编辑grafana变为可见，该指标可以看出延迟是在TiDB端还是在客户端

  • Server

    • Get token duration：最好小于1ms，若高，说明token-limit(默认1000)配置不合理
      确认token-limit数量大于连接数
      获取token，是为了对连接限流

  • Executor

    • Parse duration：最好<10ms
    • Compile duration：最好小于30ms

  • Errors：KV Errors

    • Lock Resolve OPS：对于 expired和not-expired最好小于500，否则说明冲突较多；如果业务就是有很多锁，可以考虑使用悲观锁。
    • KV Backoff OPS：对于txnLockFast和txnLock，最好小于500

  • PD Client：PD TSO .99 Wait Duration：最好小于5ms

监控指标介绍

  • Statement OPS：不同类型 SQL 语句每秒执行的数量。按 SELECT 、 INSERT 、 UPDATE 等来统计
  • Duration：执行的时间
    • 客户端网络请求发送到 TiDB，到 TiDB 执行结束后返回给客户端的时间。一般情况下，客户端请求都是以 SQL 语句的形式发送，但也可以包含 COM_PING 、 COM_SLEEP 、 COM_STMT_FETCH 、 COM_SEND_LONG_DATA 之类的命令执行的时间
    • 由于 TiDB 支持 Multi-Query，因此，可以接受客户端一次性发送的多条 SQL 语句，如： select 1; select 1; select 1; 。此时，统计的执行时间是所有 SQL 执行完之后的总时间
  • QPS By Instance：每个 TiDB 上的 QPS。按照命令和执行结果成功或失败来统计
  • Failed Query OPM：每个 TiDB 实例上，每秒钟执行 SQL 语句发生错误按照错误类型的统计（例如语法错误、主键冲突等）。包含了错误所属的模块和错误码
  • Connection count：每个 TiDB 的连接数
  • Memory Usage：每个 TiDB 实例的内存使用统计，分为进程占用内存和 Golang 在堆上申请的内存
  • Transaction OPS：每秒事务执行数量统计
  • Transaction Duration：事务执行的时间
  • KV Cmd OPS：KV 命令执行数量统计
  • KV Cmd Duration 99：KV 命令执行的时间
  • PD TSO OPS：TiDB 每秒从 PD 获取 TSO 的数量
  • PD TSO Wait Duration：TiDB 等待从 PD 获取 TS 的时间
  • TiClient Region Error OPS：TiKV 返回 Region 相关错误信息的数量
  • Lock Resolve OPS：TiDB 清理锁操作的数量。当 TiDB 的读写请求遇到锁时，会尝试进行锁清理
  • Load Schema Duration：TiDB 从 TiKV 获取 Schema 的时间
  • KV Backoff OPS：TiKV 返回错误信息的数量

TiKV

重点关注指标
image

  • Cluster
    Region：最好<50K ，否则可能需要region merge和hibernate region；太大会造成心跳检测消耗高

  • gRPC
    .99 gRPC message duration：越低越好，最好小于100ms（除了复杂的协处理器请求）

  • Thread CPU

    • Raft store CPU：better < 75% * raftsore.store-pool-size
    • Async apply CPU：better < 75%* raftstore.apply-pool-size
    • Scheduler worker CPU：better < 80% * storage.scheduler-worker-pool-size
    • gRPC poll CPU：better < 80% * server.grpc-concurrency
    • Unified read pool CPU：better < 80% * readpool.unified.max-thread-count
    • Storage ReadPool CPU：better < 80% * readpool.storage.normal-concurrency

  • Raft IO

    • Apply log duration：Raft apply 日志所花费的时间 (99.99% <30ms)
    • Append log duration：Raft append 日志并持久化到磁盘上所花费的时间 (99.99% <10ms)
    • Commit log duration：Raft commit 日志所花费的时间 (99.99% <30ms)
    • 以上项的99.999%的时间消耗

  • Raft propose

    • Propose wait duration：proposal 的等待时间的直方图 99.99% < 20ms
    • Apply wait duration：apply 的等待时间的直方图 99.99% < 50ms
    • 以上项的99.999%的时间消耗，是否有毛刺

  • Errors
    Server is busy：各种会导致 TiKV 实例暂时不可用的事件个数，如 write stall，channel full 等，正常情况下应当为 0

监控指标介绍

  • leader：各个 TiKV 节点上 Leader 的数量分布
  • region：各个 TiKV 节点上 Region 的数量分布，最好<50K ，否则可能需要region merge和hibernate region
  • CPU：各个 TiKV 节点的 CPU 使用率
  • Memory：各个 TiKV 节点的内存使用量
  • store size：每个 TiKV 实例的使用的存储空间的大小
  • cf size：每个列族的大小
  • channel full：每个 TiKV 实例上 channel full 错误的数量，正常情况下应当为 0
  • server report failures：每个 TiKV 实例上报错的消息个数，正常情况下应当为 0
  • scheduler pending commands：每个 TiKV 实例上 pending 命令的个数
  • coprocessor executor count：TiKV 每秒收到的 coprocessor 操作数量，按照 coprocessor 类型统计
  • coprocessor request duration：处理 coprocessor 读请求所花费的时间
  • raft store CPU：raftstore 线程的 CPU 使用率，线程数量默认为 2 (通过 raftstore.store-pool-size 配置)。如果单个线程使用率超过 80%，说明使用率很高
  • Coprocessor CPU：coprocessor 线程的 CPU 使用率

System Info

主要关注点

image
image755×380 107 KB

System Info 监控指标介绍

  • Vcores：CPU 核心数量
  • Memory：内存总大小
  • CPU Usage：CPU 使用率，最大为 100%。CPU %超过80%可能成为整个系统的一个瓶颈
  • Load [1m]：1 分钟的负载情况， 应小于核数，否则可能成为系统瓶颈
  • Memory Available：剩余内存大小； TiKV：usage < 60%， TiDB：20% free
  • Network Traffic：网卡流量统计
  • TCP Retrans：TCP 重传数量统计
  • IO Util：磁盘使用率，最高为 100%，一般到 80% - 90% 就需要考虑加节点

Dashboard 监控项

访问地址http://pdaddr:PdPort/dashboard
image

学习过程中参考的其他资料

2

同学你好，感谢参与 TiDB 4.0 课程的学习！

本篇笔记逻辑清晰、内容丰富，被评选为优质笔记，将额外获得 20 积分，并在 「TiDB 培训」分类下获得“置顶”权益，积分兑换规则将于近期开放，敬请关注！

期待您继续产出优质内容！

4

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。