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

🌌 运维指南 Trouble Shooting 指南
6

coprocessor pool

Coprocessor pool 可以通过以下监控来排查（下面的监控指标在 TiKV-Detail → Coprocessor Overview/detail 下）：

  1. Wait duration：请求被调度 + 获取 Snapshot + 构建 Handler 的时间总和（监控中包含 max / .99 / .95 对应的延迟）
    a. 请求被调度这个延迟不涉及 IO 和网络，仅仅和 CPU 的负载有关，如果 CPU 的负载不高，调度的时间应该可以忽略不计
    b. 构建 Handler 的时间在 CPU 负载不高的情况也可以忽略不计
    c. Snapshot 获取时间如果过长，可以按照上面讲述的内容进行排查
    d. 综上：首先应该查看 CPU 的负载情况，如果 CPU 的负载高则说明瓶颈在 CPU，否则进一步排查 Snapshot 获取慢的原因

  2. Handle duration: 使用 Handler 处理这个请求的时间，Handle 过程包含：
    a. 算子的执行依赖 CPU，可以通过 CPU 的负载来定位瓶颈是否在 CPU
    b. 最底层的算子 TableScan / IndexScan 需要使用 Snapshot 的 Range-lookup，如果 CPU 负载不高，但是 Handle duration 延迟高，则需要查看上面提到的 Block Cache/MEM hit 的情况，另外，由于 Range-lookup 是范围扫描，如果 tombstone/MVCC 太多，也会影响查询时间，该指标可通过下面提到的 Perf Statistics 监控查看

  3. TiKV-Detail → Thread CPU → Coprocessor CPU：coprocessor 线程的 CPU 使用率

    image
    image904×688 161 KB

除了以上比较重要的监控指标，也可以通过以下监控辅助排查：

  • TiKV-Detail → Coprocessor Overview → Request errors：下推的请求发生错误的个数，正常情况下，短时间内不应该有大量的错误
  • TiKV-Detail → Coprocessor Detail → DAG executors：DAG executor 的个数，重点看一下 TableScan 算子的数量，排查是否有大查询扫表将 CPU 资源占用
  • Scan keys：每个请求 scan key 的个数，如果 Scan keys 的数量特别大，会占用大量的系统资源，导致请求的延迟变大
  • Scan details：scan 每个 CF 的详细情况
  • Table Scan - Details by CF：table scan 针对每个 CF 的详细情况
  • Index Scan - Details by CF：index scan 针对每个 CF 的详细情况
  • Table Scan - Perf Statistics：执行 table sacn 的时候，根据 perf 统计的 RocksDB 内部 operation 的个数
  • Index Scan - Perf Statistics：执行 index sacn 的时候，根据 perf 统计的 RocksDB 内部 operation 的个数
1 个赞