通过kafka消费每秒五千左右的数据,读写性能明显下降,duration到了5秒,监控显示网络带宽被打满(千兆)

【 TiDB 使用环境】
操作系统:Centos7
集群:三台机器(pd,kv)
其他配置默认
image

架构:
目前只有三台机器,pd,kv等都在同三台机器上,数量都是3

【概述】
每天会从kafka消费一批数据,时间为每天8点-9点30,约1800万,消费后会入库,并选择性再次发送到kafka;

【现象】
数据增长后,26号发现服务非常多慢接口,排查发现是数据库读写性能下降,如图

排查发现,宽带莫名其妙打满,但并不确定是这个功能的影响,为此,我们27号将数据接收放到了12点

第二天的八点,数据库一切正常,到了12点,再次出现了26号8点出现的问题,带宽打满,并且读写性能严重下降。

但非常奇怪的是,影响的数据只是每秒五六千的数据插入,并且两天8点的qps对比来看,并没什么太大起伏,不太理解为什么带宽被打满了,所以问题排查遇到了一些瓶颈。

【问题与目的】
希望可以指点排查方向,将带宽占用高的原因排查出来(或别的),最终解决读写性能下降问题
我是一个TiDB新手,若需要补充任何的监控或日志,请说明,我会第一时间提供。

【TiDB 版本】
4.0.12

日志:
logs (1).zip (4.7 MB)

1赞

部署架构发一下,还有问题点的日志,tidb,tikv,慢日志等

1赞

好的,已在问题补充日志,目前只有三台机器,pd,kv等都在同三台机器上,数量都是3

1赞

看网络流量异常 建议从 慢语句和热点方向排查

按照相关内容自行排查下

2赞

感谢,我们正在排查

1赞

没有发现什么很明显的痕迹,AutoID 的QPS和duration上升的很快,不知道是否有关?

1赞

问题解决了,我们有一段幂等校验逻辑,如下图,表数据约五千万

把这段逻辑注释掉后即没有出现任何问题。

现在的问题是,为什么这段平平无奇的代码会导致问题出现:sweat_smile:

1赞

上面提到了热点导致?

1赞

我们也猜测是热点数据导致,所以定位到了那段代码。实际上,按照@ sultan8252提供的文档,总的来说并没有哪一台节点非常明显高于其他节点(但其实在不同时间还是会有一台比另外一台高百分之五百)。但相似的是,unified read pool cpu都有很高的拔升,如图,分别在三个时间段尝试执行时发生比较高的拔升:

在TiKV-Trouble-Shooting,cpu的占用中有存在一台占用比另外一台多百分之五百这样的情况

1赞

哪就是小表热点导致

1赞

看了官网的热点解释,我不是很明白,有什么推荐阅读的资料吗?
实际上我们的QPS一秒几次,一次五六百的in查询操作,然后监控是所有的cpu都飙升了,三台机器之间的差距反而是不明显的,所以我们并不能确认是不是热点问题,或者说是怎么样造成的

1赞

看你代码应该是个 distinct 语句
如果没有使用 tiflash 来加速 distinct 的时候。你大概率会出现
大量 相关内容 KV 返回给 tidb 来进行 distinct 的 hash agg 处理

从 statment summary history 找下对应语句 看下 有关 kv total key 的数量是不是在同时间段内占比最高。
建议修改验证逻辑 已 count 加 crc32 方式校验。没必要 全量结果集输出比对。

或者控制全量比对的 并发度

感谢,具体的sql并不是distinct语句,具体是类似
SELECT distinct_id FROM up_group_detail_result WHERE run_info_id = 1 AND distinct_id IN (123,123,123);

用于做一个插入前校验

但大量kv返回给tidb应该是一个非常棒的思路,我后面看一下