【TiDB 4.0 PCTA 学习笔记】- 3.7.2 The lifecycle of a SQL and relevant metrics(TiDB 的 SQL 的生命周期和关键监控指标) @2班+李响

课程名称:3.7.2 The lifecycle of a SQL and relevant metrics(TiDB 的 SQL 的生命周期和关键监控指标)

学习时长:

20分钟

课程收获:

如何定位到性能问题

课程内容:

一、TiDB

  1. 流程图

  2. Before Execution
    (1)获取Token

    • 用于限制同时执行的SQL数,避免并发过大导致TiDB崩溃
    • 通过’token-limit’配置限制
    • 通过Grafana(Get Token)查看:耗时较高说明达到了Token上限,有SQL等待

    (2)获取TSO

    • 开始事务和提交事务都会向PD获取TSO(异步获取)
    • 通过Dashboard(SQL Statement和Slow Queries)体现
    • 通过Grafana(PD TSO Wait Duration)查看:此值高说明TiDB的负载高
    • 通过Grafana(PD TSO RPC Duration)查看:此值高说明TiDB和PD之间的网络慢或PD的负载高
  3. Parse & Compile
    (1)Parse

    • Parse耗时在Dashboard(SQL Statements与Slow Queries)体现、在Grafana(Pares Duration)体现
    • 一般只有insert时高

    (2)Compile

    • 包括预处理和Compile阶段
    • 预处理包括合法性验证和类型推导
    • Compile一般在复杂查询时慢

    (3)Prepared Statements

    • 开启后可节省Parse和预处理的开销
    • 通过Grafana中的Prepare Statement Count查看是否生效

    (4) Prepared Plan Cache

    • 开启后可节省optimizing的开销
    • 通过Grafana中的Plan Cache Hits查看是否生效
  4. Execution
    (1)Execution Duration

    • 通过Execution Duration可以看出整体耗时

    (2) Expensive Executors OPS

    • 通过Expensive Executors OPS可以看出复杂算子的OPS
    • 这些算子可以调整并发度降低延迟(tidb_{operator}_concurrency)

    (3)KV Request

    • 通过KV Request可以看出TiKV请求的耗时
    • Region Error可以导致延迟(TiClient Region Error OPS)
    • Lock Resolve可以导致延迟(Lock Resolve OPS),锁冲突高
  5. DiskSQL
    是TiDB向TiKV发送请求和接收数据的接口
    (1)DistSQL Duration

    • 可以看出DiskSQL请求延时
    • 通过系统变量’tidb_distsql_scan_concurrency’控制并降低延迟

    (2)Scan Keys

    • 体现出扫描的数据量会直接影响延迟
    • 通过Dashboard(SQL Statements与Slow Queries)体现
    • 通过Grafana(Scan Keys)体现

    (3)Coprocessor、Get和Batch Get
    通过KV Request可以看出OPS

  6. Transaction
    (1)通过KV Transaction Duration可以看到事务在TiKV的耗时

    (2)Local Latch耗时因素

    • 是TiDB在事务commit之前对事务进行排序用的锁
    • 当所冲突较多时可以打开,默认是关闭的
    • 通过Dashboard(SQL Statements与Slow Queries)体现
    • 通过Grafana(Local Latch Wait Time)体现

    (3) 事务重试

    • 事务重试只在出现一部分错误时会尝试,例如写冲突
    • 通过Dashboard(SQL Statements与Slow Queries)体现次数
    • 通过Grafana(Transaction Retry Num)体现次数

二、TiKV

  1. 流程图

  2. KV Requset
    gRPC Message Duration(反应TiKV处理请求的延迟)

    • 包括kv_get/kv_batch_get和coprocessor
    • TiDB上的KV Duration延迟约等于TiKV上的gRPC Message Duration延迟network RTT延迟,如果TiDB上的KV Duration延迟与TiKV上的gRPC Message Duration延迟不对等,说明TiDB和TiKV之间的网络延迟高
  3. Transaction
    (1)Prewrite & Commit
    通过Dashboard(SQL Statement和Slow Queries)体现单个事务的量
    (2)Resolve Lock

    • 通过Dashboard(SQL Statement和Slow Queries)体现单个事务的量
    • 通过Grafana(Lock Resolve OPS)体现单个事务的量
  4. Raft Store
    Raft Store发生在写流程中,用来把Raft log同步到所有副本
    (1)Raft propose

    • Propose等待事件
    • Apply等待事件

    (2)Raft IO

    • Append log把日志追加到Raft log结尾
    • Apply log是把日志应用到数据库上
    • Commit log是提交日志
  5. Coprocessor
    (1) Coprocessor执行时间

    • 从Request Duration上查看,通常与处理的数据量相关
    • 通过Dashboard(SQL Statement和Slow Queries)体现

    (2)Coprocessor等待时间

    • 从Wait Duration上查看,如果等待时间高可以尝试打开Coprocessor cache
    • 通过Dashboard(SQL Statement和Slow Queries)体现
  6. Rocks DB
    每个TiKV有两个Rocks DB实例,一个存储Raft日志,另一个存储用户数据
    (1)Read

    • 先读取Memtable,没命中读取Block cache,没命中读取SST
    • 从这些监控项中可以找出对应的耗时以及命中次数,根据实际情况调整配置

    (2)Write

    • 观察Write duration

    (3)Compaction

    • 通过Compaction operations可以看到Compaction次数
    • 通过Compaction duration可以看到Compaction耗时

同学你好,感谢参与 TiDB 4.0 课程的学习!

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

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

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