2. gRPC
tidb-server 通过 gRPC 发送写请求到 tikv 端
2.1 gRPC CPU
gRPC 线程是一个纯 CPU 的线程，不涉及 IO 操作。
- TiKV-Detail → Thread CPU → gRPC poll CPU：表示 每个 TIKV 实例的 gRPC 线程的 CPU 使用率，建议使用率不超过 grpc-concurrency*80% ，如果使用率过高，可以考虑调整 gRPC 线程数量，不然客户端请求会因为处理不及时导致延迟加大，此时 gRPC 会成为瓶颈。
2.2 gRPC message count
在 TiKV Details 的 gRPC 的监控中，写相关的请求主要包含 kv_prewrite / kv_commit / raw_put（仅 Raw KV ） 等可以通过以下监控查看请求的数量、失败数量、延迟等情况：
- TiKV-Detail → gRPC → gRPC message count：每种 gRPC 消息的个数
- TiKV-Detail → gRPC → gRPC message failed：失败的 gRPC 消息的个数
- TiKV-Detail → gRPC → gRPC message duration：gRPC 消息的执行时间，表示请求在 TiKV 端的总耗时（这里主要关心 kv_prewrite / kv_commit 两种类型，写流程虽然也涉及读操作，但分析过程参考：读操作慢分析），通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。
- TiKV gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽打满了：
- 网络延时
Blackbox_exporter → Network Status → Ping latency: 各节点之间网络延迟情况
- 网络带宽使用情况
Overview → System info → Network Traffic: 各节点的网卡流量情况
- 反之， 如果 TiDB 和 TiKV 的时间能对的上，但是时间比较长，可以进一步查看 Scheduler Duration 慢的原因，gRPC duration 的时间等于 gRPC 线程池将这个请求分发给 Scheduler 模块以及这个命令在 Scheduler 内部执行时间的总和