TiFlash 负载不均衡,导致tidb-server响应变慢

【 TiDB 使用环境】
5.0.3

【概述】 tiflash负载不均衡

【背景】 tiflash负载不均衡

【现象】单台tiflash cpu 100%

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】

【应用软件及版本】

【附件】 相关日志及配置信息


tidb-rpt-Overview_2021-09-02T03_24_12.605Z.json (3.7 MB) tidb-rpt-Overview_2021-09-02T03_24_12.605Z.json
tidb-rpt-TiFlash-Summary_2021-09-02T03_23_06.242Z.json (4.2 MB) tidb-rpt-TiFlash-Summary_2021-09-02T03_23_06.242Z.json

1赞

麻烦反馈下集群的拓扑结构:tiup cluster display {cluster-name} ,看起来集群存在 tikv/tiflash/tidb 混合部署的情况,比如 tiflash CPU 冲高的节点是 183,该节点上同时也部署了 tikv/tidb ,这个很容易导致集群资源出现争抢。

1赞

是有混合部署的,但是183是独立部署的tiflash。

1赞

1.麻烦检查下这 4 个 tiflash 节点之间的配置是否相同,包括磁盘类型和挂载参数等;
2.可以提供下这个 tiflash 节点相关的日志,看下是否有报错信息。

1赞

磁盘都是统一,布署也是tiup进行的,布署时也用了check apply进行参数应用,不会不一样

183机器当时的日志
链接:https://pan.baidu.com/s/1nOB-MHQzWl05pD_b0kDD2Q 密码:grlx

1赞

1.从监控中看 183 tiflash 和其他 tiflash 节点已使用空间相差不大,读写的请求也没有太大差别,但 CPU 和 内存使用情况确实差异很大,麻烦反馈下 183 服务器上的 top 结果,确认下是否是 tiflash 进程引起的;
2.请问下同步至 tiflash 表副本数设置的是多少?

1赞



cpu 100%我确认是tiflashmain进程占了,现在replica 都是2

1赞

其实负载不均衡,主要原因肯定还是 SQL 身上,建议先整理一下 当前的 SQL(走 tiflash)(根据慢日志找)的,应该能找到具体涉及的 SQL和表,然后看看 这个表的 region 分布情况(这里有个可能是 你的SQL 扫描的region 就几个,即热点,不过奇怪的是 对于 tiflash 来说,大部分扫描的 key 会很多,很少出现这种热点情况,所以还是建议找到 具体的 SQL )

1赞

region当时应该是均衡,有问题节点跟其它节点的压力差这么多说不过去,而且出问题的时候确实kill了一个很大的查询,但是kill之后1个小时cpu还是很高,这怎么排查

当时的region分布 (2.1 MB) 当时的region分布
当时的慢查询 (14.8 KB) 当时的慢查询

1赞

给的文件下载不了(能再给一下这个 CPU 使用比较高的 tiflash 日志不)

1赞

这个问题又出现了,看region分布应该是均衡的

tiflash 100% (13.0 KB) tiflash 100%

tidb-rpt-TiKV-Summary_2021-09-07T06_45_48.910Z.json (1.5 MB) tidb-rpt-Overview_2021-09-07T06_45_07.603Z.json (1.7 MB) tidb-rpt-TiFlash-Summary_2021-09-07T06_44_27.753Z.json (1.5 MB) tidb-rpt-TiKV-Summary_2021-09-07T06_45_48.910Z.json
tidb-rpt-Overview_2021-09-07T06_45_07.603Z.json
tidb-rpt-TiFlash-Summary_2021-09-07T06_44_27.753Z.json

tiflash 10.102.0.128日志
链接:https://pan.baidu.com/s/11ZYTnxIcIPBAezI-CmFK9g 密码:k3w9

1赞

上面的 慢 SQL 给一下吧

1赞

慢日志
链接:https://pan.baidu.com/s/1Rr3Zp58UzfvNdBfYZUojWg 密码:7ffo

方便发一下PD这边hot read 和hot write的监控么

1赞

tidb-rpt-PD_2021-09-08T04_38_12.472Z.json (2.4 MB) tidb-rpt-PD_2021-09-08T04_38_12.472Z.json

你好,麻烦看一下这张表的数据分布:

select c.type, a.store_id, a.address, a.db_name, a.table_name, a.is_leader, a.is_index, a.cnt from (select r.db_name, r.table_name, r.store_id, s.address, r.is_index, r.is_leader, count(*) as cnt from (select s.region_id, s.db_name, s.table_name, s.is_index, p.store_id, p.is_leader, p.status from information_schema.tikv_region_status s,information_schema.tikv_region_peers p where db_name =‘shuidi_sdb_crm’ and table_name=‘rpt_sdb_crm_order_stat_history_d’ and s.region_id = p.region_id order by p.store_id) as r, information_schema.tikv_store_status s where r.store_id=s.store_id group by r.store_id, r.is_leader, s.address, r.is_index) a, information_schema.cluster_info c where c.instance = a.address order by c.type desc, a.store_id;

image

这个问题应该不是数据分布不均匀造成的,本身数据量也较小。

麻烦下次再出现的时候,去出问题的 tiflash 节点上抓一下火焰图:

curl --output profile.svg http://<tiflash_ip>:20292/debug/pprof/profile?seconds=30&frequency=99

好的,没问题,经常出现

多谢。作为对比,再拿下同时期其他节点 profile。