读性能慢-热点问题

🌌 运维指南 Trouble Shooting 指南
1

判断读热点依据

方式一：在监控面板 TiKV-Details -> Thread CPU 中查看

若开启了 Unified read pool，查看是否有某个 TiKV 的 Unified read pool CPU 明显高于其他 TiKV 节点

若未开启 Unified read pool，查看是否有某个 TiKV 的 Coprocessor CPU 明显高于其他 TiKV 节点

方式二：在监控面板 TiKV-Throuble-Shooting -> Hot Read 中查看

查看是否存在某个 TiKV 的指标明显高于其他 TiKV 节点

2 个赞
2

若确定存在读热点，需定位到具体的热点表或索引

方式一：通过 tidb dashboard 热力图定位（推荐方式）

对于读热点，在热力图中一般表现为一条明亮的横线，通常是有大量访问的小表

将鼠标移动到亮色块上可以看到具体什么表或索引上有大流量

方式二：通过 TiDB API

查询读流量最大的 Region ID

pd-ctl -u http://{pd}:2379 -d region topread [limit]

根据 Region ID 定位到表或者索引

curl http://{TiDBIP}:10080/regions/{RegionId}

1 个赞
3

读热点解决方法

根据监控面板 TiKV-Details -> RocksDB KV -> Block Cache hit 命中率来判断

  • 若 BlockCache 的命中率下降或者抖动，可能是存在全表扫描的 SQL、执行计划选择不正确的 SQL、存在大量 count(*) 操作的 SQL 等等，解决方法：
  1. 优化具体的 SQL
    若 BlockCache 命中率比较稳定，则可能是 Region 并发读取过高导致，在业务查询频繁的命中个别 Region 最终时会导致单个 TiKV 节点性能达到极限，几种解决方法供参考：
  2. 在 4.0 版本中 针对小表的读热点提供了新的解决办法 Load Base Split ，通过调整 TiKV 参数 set config tikv split.qps-threshold=2000 到一个更小的值来 解决读热点问题。具体操作方法参见链接 。
    • Load Base Split
    • 传统的方法： 将小表改造成 hash 分区表，打散 Region 分布，或者将小表热点 region leader 进行手工 split 和 transfer
  3. 若同时也存在写热点，可以使用 shard_row_id_bits 处理热点表，可以有效缓解读写热点问题
  4. 开启 Coprocessor Cache 功能，开启该功能后，将在 TiDB 实例侧缓存下推给 TiKV 计算的结果，对于小表读热点能起到比较好的效果
  5. 使用 Follower Read 功能，在一定程度上可以缓解读热点问题 此特性目前还是实验特性
4

bloom prefix是什么指标，没有搜到

5

https://zh.wikipedia.org/wiki/布隆过滤器 参考下吧

6

收到，谢谢