# PD/TiKV 相关 (B)

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

![center](./student-guide/diagram/09-TiDB-PDTiKV-02-01.png)
-------------------------------------------------------------
- PD Client - PD TSO Wait/RPC Duration：这两个指标和 TiDB 从 PD 获取 TSO 时间有关，如果发现 get tso 比较慢，可以参考 TSO 慢排查手册

- KV Request - KV Request Duration 99 by store/type：从 TiDB 发送请求到 TiKV 的响应时间，分别按 store 节点和按 type 请求类型统计；如果比较高，可能是 TiDB 和 TiKV 之间网络延迟较高、网卡带宽打满等网络因素，也可能是 TiKV 侧存在性能问题，需要进一步排查；如果部分 tikv store 节点比较高，检查相关 store 是否有热点或负载不均衡，如果某些请求如 coprocessor 耗时较高，进一步排查 SQL 执行计划是不是扫描 keys 比较多或 unified read pool 等线程池瓶颈等因素；如果 kv_prewrite/kv_commit 等提交慢，则可以参考 TiKV 写入慢 分析 TiKV 相关监控指标。
- KV Errors - KV Backoff OPS：统计了 TiDB 遇到 TiKV / PD 返回的可重试的错误类型及重试次数，常见的错误类型有
  - pdRPC：PD 访问错误，可能是网络原因或 PD Leader 异常
  - regionMiss：访问的 region 已经从当前 TiKV 迁走
  - serverBusy：TiKV 处理繁忙比如 TiKV 读写线程池打满
  - tikvRPC：TiKV 访问错误，可能是网络中断异常或 TiKV 负载过高
  - txnLock：写写冲突
  - txnLockFast：读写冲突
  - updateLeader：TiKV 返回自己不是 leader 且返回当前 leader 所在的 TiKV

- KV Errors - KV Backoff Duration：KV 每个请求重试的总时间，通过监控检查是不是重试时间过长导致响应时间上涨，如果存在重试，slow_query 表也记录了 SQL 具体的重试时间 Backoff_time。