读性能慢-TiKV Server 读流程详解

🌌 运维指南 Trouble Shooting 指南
7

其他问题：

一、读请求过程中出现错误

  • 可能出现的错误

    1. 请求是根据 tidb-server 中的 region cache 里的 region 信息进行发送的，而在实际中，部分 region 信息可能因为如下原因导致过期，主要包括：
      a. Region 发生了分裂
      b. Region 发生了合并
      c. Region 发生了调度
    2. 一个请求中的部分 Key 上可能有锁
    3. 其他错误

  • 错误是如何处理的？

    1. 如果是 Region 相关的错误，会先进行 Backoff，然后进行重试，比如：
      a. Region 信息过期会使用新的 Region 信息重试任务
      b. Region 的 leader 切换，会把请求发送给新的 Leader
      c. 如果部分 Key 上有锁，会进行 Resolve lock
    2. 如果有其他错误，则立即向上层返回错误，中断请求

  • 错误相关的监控有哪些？

    1. TiDB -> KV Errors
    2. KV Retry Duration：KV 重试请求的时间
    3. TiClient Region Error OPS：TiKV 返回 Region 相关错误信息的数量
    4. KV Backoff OPS：TiKV 返回错误信息的数量（事务冲突等）
    5. KV Backoff OPS：TiKV 返回错误信息的数量（事务冲突等）
    6. Lock Resolve OPS：事务冲突相关的数量
    7. Other Errors OPS：其他类型的错误数量，包括清锁和更新 SafePoint
    8. TiKV -> Errors
    9. Server is busy
    10. Coprocessor error
    11. gRPC message error
    12. leader drop
    13. leader missing
    14. TiKV -> gRPC -> gRPC message failed

二、MVCC/TombStone 数量太多

  • 导致版本过多的应用场景

    1. 业务使用了计数器
    2. gc时间比较长，且修改频繁

  • 版本过多导致的问题

    1. 需要更多的存储空间
    2. 同一个key的所有版本在底层存储上是相邻的，当scan一个范围的时候需要跳过很多的历史版本，同一个key的所有版本在底层存储上是相邻的，这些历史版本也会因为key的最近的版本被访问而从磁盘读取出来并缓存在block-cache中

  • 相关的监控有哪些

    1. TiKV-Detail -> Coprocessor Overview -> Total RocksDB Perf Statistics
    2. TiKV-Detail -> Coprocessor Detail -> Total Ops Details(Table Scan)
    3. TiKV-Detail -> Coprocessor Detail -> Total Ops Details(Index Scan)
    4. TiKV-Detail -> Coprocessor Detail -> Total Ops Details by CF (Table Scan)
    5. TiKV-Detail -> Coprocessor Detail -> Total Ops Details by CF (Index Scan)

  • 处理方式

    1. 调整 GC 的频率及时间
    2. 对 tikv 进行 compact 操作

三、读热点问题

  • 判断读热点依据

    1. 方式一：在监控面板 TiKV-Details -> Thread CPU 中查看
      a. 若开启了 Unified read pool，查看是否有某个 TiKV 的 Unified read pool CPU 明显高于其他 TiKV 节点
      b. 若未开启 Unified read pool，查看是否有某个 TiKV 的 Coprocessor CPU 明显高于其他 TiKV 节点
    2. 方式二：在监控面板 TiKV-Throuble-Shooting -> Hot Read 中查看
      a. 查看是否存在某个 TiKV 的指标明显高于其他 TiKV 节点

  • 若确定存在读热点，需定位到具体的热点表或索引

    1. 方式一：通过 tidb dashboard 热力图定位（推荐方式）
      a. 对于读热点，在热力图中一般表现为一条明亮的横线，通常是有大量访问的小表
      b. 将鼠标移动到亮色块上可以看到具体什么表或索引上有大流量
    2. 方式二：通过 TiDB API
      • 查询读流量最大的 Region ID
        • pd-ctl -u http://{pd}:2379 -d region topread [limit]
        • 根据 Region ID 定位到表或者索引 curl http://{TiDBIP}:10080/regions/{RegionId}

  • 读热点解决方法

    1. 根据监控面板 TiKV-Details -> RocksDB KV -> Block Cache hit 命中率来判断
      • 若 BlockCache 的命中率下降或者抖动，可能是存在全表扫描的 SQL、执行计划选择不正确的 SQL、存在大量 count(*) 操作的 SQL 等等，解决方法：
        • 优化具体的 SQL
    2. 若 BlockCache 命中率比较稳定，则可能是 Region 并发读取过高导致，在业务查询频繁的命中个别 Region 最终时会导致单个 TiKV 节点性能达到极限，几种解决方法供参考：
      a. 将小表改造成 hash 分区表，打散 Region 分布
      b. 若同时也存在写热点，可以使用 shard_row_id_bits 处理热点表，可以有效缓解读写热点问题
      c. 开启 Coprocessor Cache 功能，开启该功能后，将在 TiDB 实例侧缓存下推给 TiKV 计算的结果，对于小表读热点能起到比较好的效果
      d. 使用 Follower Read 功能，在一定程度上可以缓解读热点问题

四、Pending Task

TiKV 后台会不定时执行一些操作，比如 compaction、gc、split region 等，如果这些 任务执行时间很长，也会增加读请求的延迟

另外，尽管可能性很低，但如果执行读请求相关的任务发生了阻塞，读请求相应的时间会变长，所以我们也建议查看是否发生了 pending task，具体相关的监控，可以查看

  • tikv-detail -> task -> pending task

五、get、seek 慢

  • Get接口提供用户一种从DB中查询key对应value的方法
  • Seek()函数查找大于或等于指定key值的第一个键值对的位置

通常 get 是比 seek 操作更轻，如果 get/seek的耗时较长，可能是集群负载较高、磁盘性能出现问题，对应的耗时情况，可以通过下面指标查看：

  1. RocksDB - kv / raft
  2. Get operations：get 操作的个数
  3. Get duration：get 操作的耗时
  4. Seek operations：seek 操作的个数
  5. Seek duration：seek 操作的耗时
  6. Write operatioxins：write 操作的个数
  7. Write duration：write 操作的耗时
  8. WAL sync operations：sync WAL 操作的个数
  9. WAL sync duration：sync WAL 操作的耗时
  10. Compaction operations：compaction 和 flush 操作的个数
  11. Compaction duration：compaction 和 flush 操作的耗时
  12. SST read duration：读取 SST 所需的时间

六、grpc 超过网卡处理能力

如果 tidb-server的网卡是千兆的，可能会由于执行计划不对，扫描的数据量太多，导致 tikv 把 tidb-server 的网卡打满，影响查询速度。

  • 相关监控：
    • Overview -> System Info -> Network traffic

七、服务器资源

如果服务器资源使用显示不高，但又发现集群处于堵塞状态，需要查看是否开启了资源使用相关控制，另外 tidb 在使用中，不建议开启 swap，如果开启了，需要进行如下操作：

  1. 集群是否开启了 resource control，可在集群参数文件中查看
  2. 系统上是否采用了 numactl 对内存或 CPU 进行了资源控制
3 个赞