tiflash 负载不均衡，如何排查

🪐 TiDB 技术问题 TiFlash
,
1

【 TiDB 使用环境】
大量表做了tiflash，主要进行数据统计和报表

【现象】 业务和数据库现象

【问题】 同样的region weight，固定的节点cpu使用率高，怀疑有region 热点， 如何排查

【 TiDB 版本】 v5.1.2

【附件】 相关日志及监控（https://metricstool.pingcap.com/)

image
image921×499 102 KB

image
image1847×737 320 KB

压力固定在188 和141 节点，其他tiflash 没有压力

这段时间 慢查询,

image
image1101×888 66.7 KB

2 个赞
2

你慢SQL的这个截图选择的时间不是监控图中异常对应的时间片，你再看看那个时间的慢SQL

2 个赞
3

怀疑是有热点region， 该怎么排查。 或者说 如何让tiflash region分布更均衡。所有tiflash节点配置一样，region weight 也一样

2 个赞
4

可以参考这个帖子先排查下是哪个表导致的，同时抓一下 tiflash 的 profile 信息，多谢。

2 个赞
5

profile 信息
profile
SQL还在查

1 个赞
6

TIDB_HOT_REGIONS 也看不出什么来

image
image1127×168 17.3 KB

CPU 时间跟 Read Index OPS 曲线一致
image

7

SELECT
cat.creative_agent_tt_Id,
cat.agent_material_md5
FROM
creative_agent_tt cat
WHERE
cat.agent_creative_id = ‘171413xxx9480’
AND cat.end_time IS NULL;
这个sql 有索引 但是执行计划走的tiflash
我让他们试试 强制索引 ，咱们这个执行计划选择的时候 没有使用CBO原则吗？
EXPLAIN SELECT
cat.creative_agent_tt_Id,
cat.agent_material_md5
FROM
creative_agent_tt cat FORCE INDEX (agent_creative_id)
WHERE
cat.agent_creative_id = ‘171413xxx9480’
AND cat.end_time IS NULL;

1 个赞
8

麻烦提供下下面的信息：
集群信息tiup cluster display
异常时段Grafana TiFlash-Summary仪表盘中的TiFlash指标
所有的TiFlash日志，包括tiflash.log / tiflash_tikv.log

1 个赞
9

麻烦提供这个SQL的执行计划explain analyze

10

只是执行计划的问题 还需要提供 tiflash日志吗?
tiflash的执行计划

image
image1224×300 23.2 KB

强制索引 tikv的执行计划
image
image1230×318 26.5 KB

1 个赞
11

请用户提供一下如下信息：

  1. 所有store的信息：select store_id,address,store_state_name,label,leader_count,region_count,region_weight,region_score,region_size from information_schema.tikv_store_status;
  2. 表的数据分布： 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 =‘数据库名称’ and table_name=‘表名称’ 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.db_name,r.table_name, 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;
  3. 慢SQL的执行计划以及实际对比： explain analyze 慢SQL
  4. 执行的详细信息：trace 慢SQL，比如 trace select * from test1;
1 个赞
12

请问，你的问题跟楼主的问题不是同一个问题吧？如果不是请开新帖，谢谢。

1 个赞
13

是这个SQL 定时批量执行 导致的tiflash cpu高

1 个赞
14

image
image1319×281 33.1 KB

explain 查看之前帖子
image
image1224×300 23.2 KB

trace 慢SQL。trace 现在是正常走索引，之前 是走全表

image
image755×569 33.8 KB

1 个赞
15

是执行：explain analyze 慢SQL，你之前使用 explain，而不是explain analyze

1 个赞
16

image
image940×506 7.85 KB

1 个赞
17

可能跟参数 tidb_opt_cpu_factor=10000有关系
set session tidb_opt_cpu_factor=10; 就会优选 索引了

18

tidb 选5.1.1 就走索引， 选5.1.2 就走全表

image

id estRows actRows task access object execution info operator info memory disk
Projection_4 23.26 1 root time:954.8ms, loops:2, Concurrency:OFF yixintui_operate.creative_agent_tt.creative_agent_tt_id, yixintui_operate.creative_agent_tt.agent_material_md5 2.20 KB N/A
└─TableReader_10 23.26 1 root time:954.8ms, loops:2, cop_task: {num: 36, max: 625ms, min: 83.1ms, avg: 314.1ms, p95: 604.3ms, rpc_num: 36, rpc_time: 11.3s, copr_cache_hit_ratio: 0.00} data:Selection_9 408 Bytes N/A
└─Selection_9 23.26 1 cop[tiflash] tiflash_task:{proc max:623ms, min:82.5ms, p80:427.1ms, p95:599.3ms, iters:1, tasks:36, threads:36} eq(yixintui_operate.creative_agent_tt.agent_creative_id, “1714123543472237”), isnull(yixintui_operate.creative_agent_tt.end_time) N/A N/A
└─TableFullScan_8 23261061.00 23427983 cop[tiflash] table:cat tiflash_task:{proc max:609ms, min:70.5ms, p80:416.1ms, p95:577.3ms, iters:431, tasks:36, threads:36} keep order:false, stats:pseudo N/A N/A

tidb 5.1.1
NS8I4KG%5DH8JIXV1IF2ZHTV4

1 个赞
19

v5.3.0 的tidb 也是 按tiflash 走 。
5.3 set tidb_opt_cpu_factor=10; 也会走tikv 索引 。

20

tiflash的负载和副本数有关系吗，因为我默认设置的是2个副本，所以只有2个tiflash提供服务