【 TiDB 使用环境】
生产环境
【 TiDB 版本】
v7.5.0
【复现路径】
通过 JuiceFS 方式使用 TIKV，直连 PD。具体原因不明，可能与大量写入有关。
【遇到的问题：问题现象及影响】
故障期间 JuiceFS 大范围客户端元数据时延飙高
【资源配置】
【附件：截图/日志/监控】
下图中 gRPC message duration 飙高对应的时段为故障时段。
【附件：截图/日志/监控】
下图中 gRPC message duration 飙高对应的时段为故障时段。
这期间有没有什么操作？
存储侧是没有的，业务侧的qps可能有增高。期间 TiKV_async_request_snapshot_duration_seconds 这个指标有告警，有一个节点的 Read Pool CPU 打的比较高，有800%。
看着像是当时有大范围的数据扫描（kv scan），导致 CPU 使用率升高，进而影响了其他业务。
看一下 gRPC message count。
1 个赞
dashboar的热力图能看到有没有热点么？
故障期间，gRPC message count 基本掉0了。gRPC batch size 比较大，前后的 batch get 比较多。
1 个赞
这个我下周上班的时候关注下。
- 如果怀疑和写入有关系，可以看下 tikv detail >> schedule 监控下有个 pending 的监控面板，如果高可能是写入阻塞了
- 如果觉得和读热点有关系，可以看下 tikv detail >> thread cpu 和 read pool 相关面板，看看每个 tikv 的 cpu 是否均衡。
如果是读写热点问题看：https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues
写堆积的话，可以考虑调高一些 cf 参数：专栏 - TiDB 5.1 Write Stalls 应急文档 | TiDB 社区
1 个赞
1、检查TiKV的监控指标，特别是Grafana → TiKV → errors监控，确认具体busy原因。
2、查看TiKV RocksDB日志，确认是否存在write stall现象，这可能是由于level0 sst太多导致stall，可以通过添加参数[rocksdb] max-sub-compactions = 2（或3）加快level0 sst往下compact的速度
1 个赞