Lost connection to MySQL server during query

navicat客户端连的,现在我重启FE和3个BE之后,也是一样的,建表会很久并不会显示结果,然后我将它停止,但是过一段时间之后,新建的这个表会展示出来,似乎是创建成功了,这种情况我不知道如何去处理了,以往建表很快的

可以在mysql-client测试下,

我觉得和这个关系应该不大,navicat客户端建表用时500s,我想知道如何定位问题,其他的部分都是正常的,查询速度和以往一样

另外还有我使用dadax导入大量数据时,有时候会随机出现Failed to flush data to StarRocks.的报错,当我第二次往表里导入时,通常又不会报这个错,能顺利导完 :joy:

一次创建这么多分区确实是会很慢的。

Failed to flush data to StarRocks. 有具体报错的。出现的话可以在论坛提新的帖子。


因为是偶发性质的,我不确定要不要发个新帖子

delete目前效率不太好,集群有很多删除吗?这个队列是排队的,失败也不会取消任务,也是一直排队,所以删除的时候一定要指定分区去删,不然一堆任务会给每个be都发大量删除任务占用队列,前面没指定分区删的话,他会发大量删除任务,即使删除失败了,这些任务也没有cancel掉,导致后面的新的任务也会失败掉

整表删除、删数据库也会造成这样的情况吗,我有操作整表删除,删数据库

drop/truncate的话不会,delete跟drop机制不一样。

我几乎没有进行delete操作,都是drop/truncate,看be CPU Idle也处于85%左右,可是建表和truncate用时都非常久,但是确实又能成功,其他的查询又是正常的1s左右,我不知道问题出在哪
image

当前使用的是哪个版本?

2.2.0 1fe+3be 16核+64G

这些操作是fe的操作,可以看下fe.conf里的jvm大小是多少,你这个很可能是fe压力比较大了,可以适当调大jvm的大小并重启fe看看。

jvm调大了之后(8g->16g)我进行了简单的测试,调大之后依然需要很久,即使是一个空表,虽然分区有331个,但是也不算很多吧,而且都是空的,问题应该是其他原因导致的。


在等待命令"TRUNCATE TABLE common_asset_info_0606_copy2 "完成的时候,我对一个没有分区的简单表执行清空命令,出现如下报错,当上面的命令完成之后,下图里的命令很快就完成了不报错,首先是报错语句是创建表超时,但我只是执行清空表命令,其次两个清空命令为什么不能同时执行呢?

目前truncate原理是创建新的空tablet,认后再swap。这331个分区每个分区设置的bucket是多少?默认3副本可以算下总共的tablet数量。如果太多的话效率会下降,或者你指定分区去truncate,看下效率

tablet 是23,832,243331,5s的那次还算正常,4min就不正常了,即使tablet多效率下降,4min肯定也是不正常的

因为这里是队列排队,所以可能是前面有任务积压导致的,这块我们在优化,目前的话可以在ddl操作的时候规划一下,不要同时做很多类似的操作,另我们建议单tablet数据量大概在100MB-1GB之间,单表这么多tablet还是根据数据量早点规划下合理的tablet数值,tablet太多查询和写入性能都不好

好的,谢谢解答,因为数据比较分散,分区不是很方便划分,造成了tablet虽然多但是大部分都是空的,这会对性能造成影响吗

小文件影响挺大的,尤其是不指定分区去做一些元数据操作的时候,对fe压力挺大,如果天级别数据量小,可以按月或者年去分,以及减少单分区的bucket数量,按照这些思路去规划下建表。

我发现只有主键模型建表慢,更新模型,明细模型,不论我分区多少,几秒就好了,主键模型分区少一点,也要几百秒,请问是什么原理呢