如果方便拆分,其实更适合使用 Placement Rule 在 TiKV 层来隔离一下。 也可以升级一下集群版本,使用下 Resource Control 来限制跑批可以使用的资源(可能会大幅度增加跑批的执行时间,需要业务部门评估)
这个需要看下是什么 SQL 导致的 CPU 高。如果是 TiFlash 节点负载高,大概率是并发比较大的 SQL 跑到了 TiFlash 上了。有时候 TiKV 和 TiFlash Cost 相近时候,会误使用 TiFlash 来运行,而 TiFlash 在高并发场景下表现又特别差,可能会引起问题。 可以对特定场景的 SQL 主动设置tidb_isolation_read_engines='tikv,tidb',让其不走TiFlash。
这里贴一下群里的反馈总结:
为什么会导致分布倾斜?
PD 目前没有对象存储使用量的上报口。如果 tiflash 把对象存储的使用量当作 used size 上报,当对象存储的存储量接近本地盘容量的话,会导致 PD 停止调度 region 到那个 store 上。无法达到减少 write node 硬件成本的目的。
目前 write node 上报的 store 的使用量按照本地盘算,确实可能会导致调度不均衡。
最终会达到稳态么?
TiFlash 的数据分为 Delta 层(新写入的小数据块)和 Stable 层。Delta 层的数据写入后累积达到阈值(一般 100w 行左右)会 Co…
现在开启 TiFlash 存算分离架构,不能设置内存限制,设置会导致本来能跑过的 SQL 跑不过去了,去掉限制后,又会导致本来一些想限制的 SQL 跑成功了,直接引起 TiFlash OOM了,头疼[苦涩]。
[image]
上面是执行时的报错内容,可以看到执行成功时内容是"memory_peak\":143686734598,换算了下是 133.82 G,已经超过机器的内存值了。 详细的 analyze 信息是
analyze.txt (78.4 KB)
或者就是,过段时间直接 display 看下新扩容节点的状态,看是不是变正常了
PS: 其实在执行成功时候配置文件参数也要跟着改profiles.default.max_memory_usage_for_all_queries = 0, 默认是0.8,预估超过机器内存的80%也会报错。
另外在跑的时候,也没有启动落盘,而是跑的时候直接报错让 SQL 中断了。。
[image]是不是统计信息有问题? 执行下 show stats_healthy看下健康度吧。
是的,我现在就是这么来解决的,加了个定时任务在数据读取之前,进行下 ANALYZE TABLE。不过奇怪的是,之前在非分区表下,即便没有 ANALYZE 也没有报错,感觉还是分区表有啥特殊处理导致的。
锁统计信息没用,应该会更差,就跟上面说的。统计信息认为当天没有新插入的数据,所以才使用的 HashJoin,你锁定了统计信息,不还是一样的。
重试了一下,执行成功了,后续重复执行了几次,也都正常了。 这个报错内容是指?
将 write node 的内存调大到 32G,确实能执行下去了,但是换成其他错了。。
ERROR 1105 (HY000): other error for mpp stream: Code: 0, e.displayText() = DB::Exception: Receiver state: ERROR, error message: Code: 0, e.displayText() = DB::Exception: Receiver state: ERROR, error message: Exchange receiver meet error : Poco::Exception.…
write node节点 内存确实也有11G 左右了,不过write node 不承载主要的查询请求,内存使用量也这么大,是需要将所有 region 的状态信息放在内存里么?
另外有参数可以调整这个限制么?发现将tiflash_query_spill_ratio这个参数调整成0.85后,报错还是limit of memory for data computing : 11.98 GiB.并没有跟着变大