stream load 导入大量数据一段时间后 导入越来越慢

  1. top -Hp be进程 截图

    2.iotop 截图
  2. "在BE日志里看下stream load的profile,看下是哪个阶段耗时 " be 日志中搜索profile关键字 没找到

lsof -p $be_pid|grep '/data1’|grep ‘w’|sort -k7 -rn|head
lsof -p $be_pid|grep '/data1’|grep ‘u’|sort -k7 -rn|head
看下是哪个表的IO比较大,是索引还是数据

这个图显示读写厉害就是主键索引,表结构方便发一下吗

CREATE TABLE xxxxx (
id bigint(20) NOT NULL
xxx_id bigint(20) NOT NULL DEFAULT “0” ,
xxx_id int(11) NOT NULL DEFAULT “0” ,
xxx_time datetime NOT NULL DEFAULT “1970-01-01 00:00:00” ,
xxx_time datetime NULL ,
xxx_time datetime NULL ,
is_xxx tinyint(4) NOT NULL DEFAULT “0"”
) ENGINE=OLAP
PRIMARY KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 114
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“enable_persistent_index” = “true”,
“replicated_storage” = “true”,
“compression” = “LZ4”
);


show tablet xxx;看下这些tablet是不是同一个表,这个表结构有什么特别吧

都是同一张表的。表结构没啥特别的

没有bitmap索引,bloom索引吧?

CREATE TABLE XXX (
id largeint(40) NOT NULL ,
XXX largeint(40) NOT NULL DEFAULT “0” ,
XXX varchar(65533) NOT NULL ,
XXX varchar(65533) NOT NULL,
XXX varchar(65533) NOT NULL ,
XXX varchar(65533) NOT NULL ,
XXX datetime NULL,
XXX datetime NULL ,
XXX smallint(6) NOT NULL DEFAULT “0”,
XXX varchar(65533) NOT NULL
) ENGINE=OLAP
PRIMARY KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 192
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“enable_persistent_index” = “true”,
“replicated_storage” = “true”,
“compression” = “LZ4”
);

strem load 导入主键表 磁盘读放大 这个帖子也是我发的,一样的问题 只是版本不一样

嗯,大概懂了,RD那边有个设置可以配置后测试一下,请稍等。

好的 非常感谢,有进展了 麻烦同步下。

be配置加上
enable_parallel_get_and_bf = false
测试一下

测试了 ,刚开始还好,后面导入速度越来越慢,最后还是读放大
zabbix 磁盘读

iotop

sr 版本:最新版本 3.2.1
添加参数如下:
enable_parallel_get_and_bf = false
flush_thread_num_per_store=5

cumulative_compaction_num_threads_per_disk =10
base_compaction_num_threads_per_disk = 4
cumulative_compaction_check_interval_seconds = 1
base_compaction_check_interval_seconds=10

大佬,有时间帮看下

我也遇到了相同的问题,请问现在有进展吗

我们也遇到这个问题,版本3.1.5

这个问题好普遍呀,并且看起来都是SR3.1.x?

@U_1702279254026_8000 请问你解决了吗,我也遇到同样问题,存算分离 3.2.8数据量60亿左右,越到后面越慢,持久化索引占用大量IO

@U_1702279254026_8000 @richie 这个问题目前解决了吗。我们前两天也遇到了同样的问题。