背景
前段时间线上的tidb集群,偶尔收到告警tikv节点报CPU使用率超过80%,也有业务方反馈tidb集群上的业务SQL偶尔会变慢,正常情况表都是毫秒级别的,并且慢的时间点和tikv CPU使用报警的时间点都吻合,这个集群的业务一直在增加,并且已知的有几个SQL是表扫,所以基本可以确定是tikv节点CPU瓶颈了,tikv集群在原来的3台基础上扩容了4个节点,扩容完成后发现各个节点的region分布比较均匀,但是leader分布就很不均匀,新加的4个节点上leader要比原来3台上的leader少很多,如下图:
集群版本:3.0.14
问题定位
- 因为缺少相关经验,定位过程走了不少弯路,针对上面问题的定位,通过下面方法基本直接可以定位到问题
- 查看各个tikv节点的leader_weight、region_weight值是否均匀,如果每台tikv的配置都一样,正常情况下,那每台的值应该是相等或者相近的
热点问题定位知识扩展
- 通过监控定位热点问题
- 判断写热点依据:打开监控面板 TiKV-Trouble-Shooting 中 Hot Write 面板(如下图所示),观察 Raftstore CPU 监控是否存在个别 TiKV 节点的指标明显高于其他节点的现象。
- 判断读热点依据:打开监控面板 TIKV-Details 中 Thread_CPU,查看 coprocessor cpu 有没有明显的某个 TiKV 特别高。
- 通过pd-ctl获取热点region的信息
- 跟进上面获取到的region ID定位是哪张表,是表数据还是索引
- 如何判断一张表的region leader 分布是否均已
- 通过tikv的日志找到热点表的region ID和table ID
- 通过表的ID查找表名
- 大region定位,主要关注approximate_size(单位是MB),approximate_keys(这个region key的数量),当region的大小超过200MB算是大region了,可以通过下面方法拆分
- 4.0的流量热力图定位热点杀手锏\
如何解决
- 通过人工干预,调整各个tikv节点的leader weight值,让其各个节点相等
- 查看tikv的ID和地址的对应关系
- 设置 store id 为 179309 的 store 的 leader weight 为 5,Region weight 为 1
- 把热地region或者大region拆分
- 把ID为252868的region对半拆分成两个region
- operator add split-region 1 --policy=approximate // 将 Region 1 对半拆分成两个 Region,基于粗略估计值,消耗更少的 I/O,可以更快地完成。
- operator add split-region 1 --policy=scan // 将 Region 1 对半拆分成两个 Region,基于精确扫描值,更加精确
参考文档
https://book.tidb.io/session4/chapter7/hotspot-resolved.htmlhttps://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues
TiDB 常见问题处理 - 热点 运维实战
作者:李坤,PingCAP 互联网架构师,TUG Ambassador,前美团、去哪儿数据库专家。 背景 从现有的数据库使用场景来看,随着数据规模的爆发式增长,考虑采用TiDB这种分布式存储的业务,通常都是由于触发了单机数据库的瓶颈,我认为瓶颈分为3点:存储瓶颈、写入瓶颈、读取瓶颈。我们希望TiDB能够解决这3个瓶颈,而存储瓶颈是可以首先被解决的,随着机器的扩容,存储瓶颈自然就可以几乎线性的…
https://pingcap.com/docs-cn/v3.0/pd-control/\
TiDB 性能问题排查常用操作 运维实战
性能问题排查常用操作 基本原则 应用压测目标 当前机器拓扑和资源下 测试出压测程序压测 TiDB 集群,QPS 和 TPS 的 “天花板” 平均响应时间和最高响应时间满足需求 常见优化思路 热点优化,当前主键热点可以使用 shard bits 的方式进行优化 对于索引热点暂时无法优化,后期可以使用离散列做分区表,可以解决该问题 业务逻辑冲突优化,比如会有同时修改一行的场景。 按照压测场景…