# Duration 相关 (B)

+ `Grafana` 监控 TiDB --> KV Request --> KV Request Duration 99 by type

![center](./student-guide/diagram/09-TiKV-Duration-02-01.png)
-------------------------------------------------------------
- Duration 相关
  - gRPC - 99% gRPC message duration：请求在 TiKV 端的处理总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV Request duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间可能网络延迟很高或者网卡带宽打满。

  - Scheduler - Scheduler command duration：执行 scheduler 相关命令如 prewrite/commit/get/batch_get 所花费的时间，如果比较高需要进一步检查以下 Scheduler latch wait duration 以及 Raft 相关的写入延迟。

  - Scheduler - Scheduler latch wait duration：由于 latch wait 造成的时间开销，latch 的目的是让修改同一个 key 的请求串行执行，当同一个 key 写入冲突严重，latch wait duration 会比较高；另外当 scheduler 写入堆积时也会导致 latch wait duration 较高，可以查看 Scheduler - Scheduler writing bytes 指标是否超过了 [storage] scheduler-pending-write-threshold 设置的流控阈值。

  - Raft IO - Append log duration：Raft append 日志所花费的时间，把 raft log 写入到 raftdb 的耗时，如果比较高，进一步排查 Raft RocksDB 慢的问题。

  - Raft IO - Apply log duration：Raft apply 日志所花费的时间，执行 raft log 把数据写入到 kvdb的耗时，如果比较高，进一步排查 KV RocksDB 慢的问题。

  - Raft IO - Commit log duration：Raft commit 日志所花费的时间，将日志通过 raft 发送给其他 Raftstore 线程处理写入，如果有热点写入并且 commit log duration 比较高可以适当调大 raft-max-inflight-msgs 参数。

  - Raft Propose - Propose wait duration：发送请求给 Raftstore 到 Raftstore 真正处理请求之间的延迟。如果该延迟比较高，说明 Raftstore 比较繁忙或者 append log 比较耗时导致 Raftstore不能及时处理请求。

  - Raft Propose - Apply wait duration：committed raft log 发送给 apply 线程到 apply 线程真正 apply 这些 log 之间的延迟。如果该延迟比较高说明 apply 线程比较繁忙。需要查看是否是因为 apply CPU 过高导致的或者由于磁盘负载比较高导致。