tidb3.0.11关于KV监控参数解读，以及该如何解决问题？

[leojiang]

tidb版本3.0.11，生产环境。四台kv统一都是8核64Gssd500G

查看 Overview面板中关于tikv-cpu使用的参数Coprocessor CPU发现使用达到了瓶颈.，region不均衡。

1、想问下着种情况是正常情况，还是……
2、这种情况该如何定位是什么类型sql引起的。
3、如何定位高并发sql
4、为什么同样的配置每台kv-region相差这么多

这种情况该何如解决定位，请各位老师帮忙解惑下，感谢！

空region该如何消除，tidb自身并没有删除空region。

[Lucien]

@leojiang

1、想问下着种情况是正常情况，还是……
2、这种情况该如何定位是什么类型sql引起的。
3、如何定位高并发sql
4、为什么同样的配置每台kv-region相差这么多

1、Coprocessor CPU 达到瓶颈是怎么判断的 ？能不能发一下对应的监控截图，可以发一下 TiKV-details 的 dashboard 下面的 Thread CPU 和 Coprocessor Details 的监控面板的监控，帮你确认一下。
2、Coprocessor CPU 如果是瓶颈，可以从两个方面分析

• 通过 slow log 查询一下 cop 请求比较多的 sql ，尝试左右一些 SQL 优化；
• 如果 SQL 执行计划是预期的，可以考虑增加 coprocessor CPU 的并发线程数；
  3、可以通过 TiDB 的系统表 information_schema.slow_log 表，通过 digest 地段进行统计排序，定位执行次数多的 sql，并进行分析；
  4、麻烦发一下 PD Dashboard 下面的 operator 和 balance 面板下面的监控，确认一下对应的 tikv 的 leader、region 调度情况。

慢日志相关文档：https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries#慢查询日志

[leojiang]

多谢老师。
1、这个是这种cpu使用是正常现象么？

4、PD Dashboard 下面的 operator 和 balance 面板下面的监控，这个主要看哪些参数啊。

[Lucien]

@leojiang

1、这个是这种cpu使用是正常现象么？

在 24、26 存在读请求热点，可以排查 tikv 的日志和 tidb 的 slow log 看看是不是慢查询；

@leojiang

4、PD Dashboard 下面的 operator 和 balance 面板下面的监控，这个主要看哪些参数啊。

主要关注一下 store region/leader size 是否均衡，从监控看是均衡的，但是 leader/region count 是不均衡。能耐是存在 region size 差异，大 region 或者空 region 都会导致 count 不均衡。PD 在调度 leader score 的计算逻辑是基于 Region size, 所以可能出现 leader Region Size 分布均匀，但是 leader Region Count 相差很大的情况。
可以考虑通过调整 pd ctrol 的 region merge size/key 的阈值，来优化调度逻辑，应该会有改善。

[leojiang]

有一台kv cpu使用不降，这种情况该怎么定位是什么原因产生的啊

[QBin (Bin)]

你好。建议可以参考热点的文章进行排查看看是否热点问题导致。
https://asktug.com/t/topic/1123