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

xuanzjie · 2021 年9 月 27 日 08:54

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

架构：
目前只有三台机器，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)

songxuecheng · 2021 年9 月 27 日 09:28

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

xuanzjie · 2021 年9 月 27 日 10:15

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

sultan8252 · 2021 年9 月 28 日 03:13

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

按照相关内容自行排查下

xuanzjie · 2021 年9 月 28 日 03:23

感谢，我们正在排查

xuanzjie · 2021 年9 月 28 日 07:28

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

xuanzjie · 2021 年9 月 28 日 08:50

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

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

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

spc_monkey · 2021 年9 月 28 日 10:07

上面提到了热点导致？

xuanzjie · 2021 年9 月 28 日 10:31

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

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

spc_monkey · 2021 年9 月 29 日 06:46

哪就是小表热点导致

xuanzjie · 2021 年9 月 29 日 06:59

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

sultan8252 · 2021 年9 月 30 日 01:58

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

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

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

xuanzjie · 2021 年9 月 30 日 03:48

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

用于做一个插入前校验

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

system · 2022 年10 月 31 日 19:22

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。