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

liqingqiang · 2021 年9 月 2 日 03:19

【 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

这道题我不会 · 2021 年9 月 2 日 06:00

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

lxzkenney · 2021 年9 月 2 日 06:36

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

这道题我不会 · 2021 年9 月 2 日 07:13

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

liqingqiang · 2021 年9 月 2 日 07:43

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

183机器当时的日志
链接:百度网盘-链接不存在密码:grlx

这道题我不会 · 2021 年9 月 2 日 09:48

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

liqingqiang · 2021 年9 月 2 日 11:26

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

spc_monkey · 2021 年9 月 3 日 02:18

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

liqingqiang · 2021 年9 月 3 日 08:26

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

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

spc_monkey · 2021 年9 月 6 日 07:15

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

liqingqiang · 2021 年9 月 7 日 04:13

这个问题又出现了，看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日志
链接:百度网盘-链接不存在密码:k3w9

spc_monkey · 2021 年9 月 8 日 01:47

上面的慢 SQL 给一下吧

liqingqiang · 2021 年9 月 8 日 02:29

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

bufferflies · 2021 年9 月 8 日 02:43

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

liqingqiang · 2021 年9 月 8 日 04:39

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

flow-PingCAP · 2021 年9 月 8 日 07:10

你好，麻烦看一下这张表的数据分布：

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;

liqingqiang · 2021 年9 月 8 日 07:14

flow-PingCAP · 2021 年9 月 8 日 07:44

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

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

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

liqingqiang · 2021 年9 月 8 日 08:03

好的，没问题，经常出现

flow-PingCAP · 2021 年9 月 8 日 09:04

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