当前位置:   article > 正文

doris版本1.1.1 内存持续增长,版本升级到1.1.5稳定版本的记录_doris稳定版本

doris稳定版本

2022年12月下载了doris1.1.1之后出现了各种问题,其中最重大的是内存持续缓慢增长,直至超过最大mem_limit限制后仍旧增长
更改前:
在这里插入图片描述
期间为了解决这个问题更改了:

------------------主要调控内存现象
trash_file_expire_time_sec=86400   		#清理文件的时间间隔(秒)
total_permits_for_compaction_score=1000 #合并文件的同时进行数  默认10000   是消耗内存的大客户  
max_segment_num_per_rowset=200			#用于限制导入 新产生的 rowset中的segment数量
描述: 用于限制导入时,新产生的rowset中的segment数量。如果超过阈值,导入会失败并报错 -238。
过多的 segment 会导致compaction占用大量内存引发 OOM 错误。
segment_cache_capacity=100000			#Segment Cache 缓存的 Segment 最大数量
默认值目前只是一个经验值,可能需要根据实际场景修改。
增大该值可以缓存更多的segment从而避免一些IO。减少该值则会降低内存使用。
write_buffer_size=104857600				#默认值:104857600
刷写前缓冲区的大小
导入数据在 BE 上会先写入到一个内存块,当这个内存块达到阈值后才会写回磁盘。
默认大小是 100MB。过小的阈值可能导致 BE 上存在大量的小文件。
可以适当提高这个阈值减少文件数量。但过大的阈值可能导致 RPC 超时。
load_process_max_memory_limit_percent=48318382080 #最大写入单节点上所有的导入线程占据的内存上限
将这些默认值设置得很大,因为我们不想在用户升级 Doris 时影响负载性能。 如有必要,用户应正确设置这些配置。
mem_limit=30%
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17

只是减缓了内存的增长速度并没有解决内存缓慢增长的问题,官网浏览版本更新介绍在1.1.3版本中有介绍说1.1.0-1.1.2版本都是没有解决内存缓慢增长的问题,只能检索版本查看稳定版,最新的1.2.X性能强大,但是刚出现并不能确定版本是否稳定,能确定较稳定的版本只有0.15和1.1.5,但是0.15 相对性能较差,因而选定了1.1.5。
下面来说更新版本的操作:
sql 执行

admin set frontend config("disable_balance" = "true");
admin set frontend config("disable_colocate_balance" = "true");
admin set frontend config("disable_tablet_scheduler" = "true");
  • 1
  • 2
  • 3

停止文件的交换和写入。
下载apache-doris-fe-1.1.5-bin.tar.gz 和 apache-doris-be-1.1.5-bin-x86_64.tar.gz分发到对应的fe、be节点,解压。
1、停止FE,重命名fe数据存储目录为fe-two,作为备份
在fe的fe.conf中有:
meta_dir=/datassd03/doris/doris-meta

sh stop_fe.sh
cp -r /datassd03/doris/doris-meta /datassd03/doris/doris-meta_two
  • 1
  • 2

2、停止BE,重命名be数据存储目录be为be-two,作为备份
在be的be.conf中有:
storage_root_path = /datassd03/doris/disk1/data

sh stop_be.sh
cp -r /datassd03/doris/disk1/data /datassd03/doris/disk1/data_two
  • 1
  • 2

3、fe 主节点fe.conf 添加 metadata_failure_recovery=true 多个fe节点先只启动一个作为master节点。

sh  start_fe.sh --daemon
  • 1

4、启动BE

sh start_be.sh --daemon
  • 1

5、查看log日志检测是否成功
6、成功后,可选择删除two后缀文件夹
7、其他fe节点 ,删除本地的存储文件,删除后重新添加
删除除了已经启动的master节点外的所有fe节点
要注意的是先前保存的fe.conf中meta_dir对应的目录要删掉后重新创建新的,用来加载元数据。

ALTER SYSTEM drop FOLLOWER "follower_host:edit_log_port";
  • 1

启动:

./bin/start_fe.sh --helper master_fe_host:edit_log_port --daemon
  • 1

添加

ALTER SYSTEM add FOLLOWER "follower_host:edit_log_port";
  • 1

一天后运行所有已有程序内存展现:

在这里插入图片描述

成功解决。
题外话:
源数据同步理论上是没啥问题了,但是我这里查询一些表报编号-230错误,最后sql尝试删除后从回收站恢复:

drop table database_name.table_name;
RECOVER TABLE database_name.table_name;
  • 1
  • 2

并且设置了参数:
ignore_rowset_stale_unconsistent_delete=true

–文件修复 报错 detailMessage = Failed to get scan range, no queryable replica found in tablet: 9719453
show tablet 9719453;
----将字段DetailCmd 值粘出执行
SHOW PROC ‘/dbs/10018/7901884/partitions/7901883/7901885/7901898’;
----可以查到backend_id 给文件的状态付给bad值 ,有副本的话 会自动恢复副本文件
ADMIN SET REPLICA STATUS PROPERTIES(“tablet_id” = “7901898”, “backend_id” = “10110”, “status” = “bad”);

如果没有副本,

当确认数据已经无法恢复后,可以通过执行以下命令,生成空白副本
ADMIN SET FRONTEND CONFIG (“recover_with_empty_tablet” = “true”);
五分钟后执行
查询 报错的表,正常展示
ADMIN SET FRONTEND CONFIG (“recover_with_empty_tablet” = “false”);

以上如果无法解决就得清空表重新运行

SHOW PROC ‘/cluster_health/tablet_health’; —查看整个文件系统的健康状态 会显示各种文件状态

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Gausst松鼠会/article/detail/455511
推荐阅读
相关标签
  

闽ICP备14008679号