tidb集群存在热点读问题,tikv的3个节点在某个时间段内读流量高达3Gb问题,导致整个集群的查询性能变慢

【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.0
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】tidb集群存在热点读问题,tikv的3个节点在某个时间段内读流量高达3Gb问题,导致整个集群的性能变慢
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】


和region相关的几个配置参数如下:

  tikv:
    coprocessor.region-max-size: 384MB
    coprocessor.region-split-size: 256MB
    raftstore.region-split-check-diff: 196MB
+-----------+----------------------------------+-----------+------------------+------------------+-----------+------------------+
| 数据库    | 表名                             | 记录数    | 数据容量(GB)     | 索引容量(GB)     | total(GB) | 碎片占用(MB)     |
+-----------+----------------------------------+-----------+------------------+------------------+-----------+------------------+
| maindb    | es_charge_settle_accounts_detail |   8303620 |             3.51 |             1.46 |      4.97 |             0.00 |
+-----------+----------------------------------+-----------+------------------+------------------+-----------+------------------+
1 row in set (0.25 sec)

表的记录数和占用空间大小情况

应该让表妹给宣传下,看看有没有大佬能解决

已经告知表妹了,哈哈

一共几个kv节点??

3个kv节点。

那你这个不是热点读写,是这个detail表有大规模的读写压崩了数据库,得优化sql

dashboard慢查询页面看下这个表的对应sql及执行计划,是不是全表扫了。

你就3个tikv,那就没啥热点,3个看起来都高,找慢查询看看sql为啥取那么多数据

1、前几个月的时候,也出现过类似的情况。当时,是因为某张业务表的健康度过低。做了analyze收集后,就解决了。
2、后来,我们专门对业务表,进行了一个定时自动进行低健康度的表信息收集。
3、这次的问题现象虽然和上次很像,但是,这次的表的健康度为100%。
4、目前,查看到的象是产生了热点读,但是,这张表只有800w数据。

看下你的这个表的慢sql呢,是不是执行计划走偏了

根据官方文档排查热点读写的思路,看到的流量可视化的热力图,以及grafana的监控情况,象是产生了热点读。



这两个时段的大量的读操作,每次,查询的row_还不一样,是不是说明进行了全表扫描呢?

1 个赞

排查这个时间段的和这张表有关的慢SQL,并没有发现有很慢的SQL:

这个图看上去确实像是读热点。

不过大表读热点确实可用的手段比较少。

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#打散读热点

使用副本读是一种方式。不过看介绍这个需要7.1.

还有就是通过top sql看看这台tikv上当时运行的sql是什么。如果是和聚合计算相关的sql,考虑使用tiflash。比使用tikv硬算要快很多。

这种热点主要是异常SQL导致的,建议先看下慢日志

问题挺复杂,学习了。