IT俱乐部 Linux Apache Doris 中Compaction问题分析和典型案例分析

Apache Doris 中Compaction问题分析和典型案例分析

说明

此文档主要说明一些常见compaction问题的排查思路和临时处理手段。这些问题包括

  • Compaction socre高
  • Compaction失败
  • compaction占用资源多
  • Compaction core

如果问题紧急,可联系社区同学处理
如果阅读中有问题,可以反馈给社区同学。

1 compaction score高

找出score最高的若干个tablet,一般是用户比较高频导入的表

分析score最高的tablet形成的原因,以下几个为常见的原因

1.1 compaction持续失败导致的compaction socre高

判断方式:
1 grep ${tablet_id} be.INFO | grep compaction,看是否有持续失败的日志

2 curl ip:port/api/compaction/show?tablet_id=${tablet_id} ,可以看curl命令查看compaction status,目前只有base的status。

处理方式:参照第2节进行处理

1.2 用户使用不当

1.2.1 建表时,bucket数量设置的不合适。

设置的太小,导致的compaction可能不能充分并发执行。

设置的太多,可能会有比较多的compaction任务调度。

建议根据tablet 1GB – 10GB的最佳实践,设置bucket数量

其他使用不当的方式,待补充…

1.3 compaction策略问题

score很高的tablet,却很久没有执行过compaction

判断方式:

1 通过curl ip:port/api/compaction/show?tablet_id=${tablet_id} 查看tablet compaction上一次执行的时间。

2 grep ${tablet_id} be.INFO | grep compaction,看该tablet compaction执行的历史,是否该tablet很长时间没有进行compaction

处理方式:

1 临时处理手段,手动触发compaction:

curl -X POST http://be_host:webserver_port/api/compaction/run?tablet_id=xxxx&compact_type=cumulative

2 这类问题可能是策略的bug,需要联系社区同学跟进处理,需要以下信息

Compaction score的监控

Compaction score从低到高涨上来时BE的日志

Compaction score比较高的tablet的rowset 布局,通过curl ip:port/api/compaction/show?tablet_id=${tablet_id} 可以拿到

1.4 导入速度超过了compaction的速度

这里又分为两种情况

1.4.1 cpu负载不高

可能是compaction的并发不够,需要调整下面这些配置(根据情况修改)

max_base_compaction_threads 默认是4
max_cumu_compaction_threads 默认是每个盘1个
compaction_task_num_per_disk,默认是4
compaction_task_num_per_fast_disk,默认是8

判断方式:

1 查看compaction 一段时间内的平均并发数

cloud使用这个命令

grep -i compaction be.INFO | grep -i finish | awk '{print $8}' | awk -F| '{print $1}' | awk -Fms '{print $1}' | awk -F= '{sum+=$2} END {print sum}'

开源doris使用这个命令

cat be/log/be.INFO | grep -E "succeed to do base compaction|succeed to do cumulative compaction" | awk '{print $23}' | awk -F= '{print $2}' | awk -Fs '{sum+=$1} END {print sum}'
  • 用上述的命令统计一段时间内compaction的总耗时(注意,cloud统计出的耗时单位是毫秒,而社区统计出的耗时单位是秒)。比如耗时是4000秒
  • 计算统计的clock time,比如统计的日志文件包含14:00 到 14:20日志,那clock time = 20min * 60 = 1200秒
  • compaction的平均并发 4000 / 1200 = 3.3 并发

2 获取BE的配置的并发限制和compaction线程数量,查看BE conf,如果没有配置则为默认
如果实际的并发已经接近设置的并发,则是并发不足

1.4.2 cpu负载比较高

处理方式:

1 如果BE的负载比较高,且用户的导入比较高频,看下能否攒批导入,降低导入频率

2 如果导入频率也不高,则需要考虑扩容

1.5 compaction score持续升高,导致导入报-235

这种现象之前出现的比较多,单独列出来,这是一个现象,原因可能还是上述的一种,针对此现象有一个临时的处理手段,如果对报-235的表没有频繁的导入和查询,可以适当调大max_tablet_version_num。这只是一个临时手段,还是要找到compaction score升高的原因
max_tablet_version_num,默认值是2000

2 Compaction 失败

2.1 定位问题

通过grep compaction be.INFO | grep {tablet_id} 查看compaction失败的具体原因。
原因包括但不限于,内存分配失败,compaction数据校验失败

2.1.1 内存问题

内存分配失败会有类似一下日志

W0427 19:40:58.254163 7873 compaction.cpp:372] fail to do CloudBaseCompaction. res=[MEM_LIMIT_EXCEEDED]PreCatch error code:11, [E11] Allocator sys memory check failed: Cannot alloc:5148, consuming tracker:
135202205>




本文收集自网络,不代表IT俱乐部立场,转载请注明出处。https://www.2it.club/server/linux/12966.html
上一篇
下一篇
联系我们

联系我们

在线咨询: QQ交谈

邮箱: 1120393934@qq.com

工作时间:周一至周五,9:00-17:30,节假日休息

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

返回顶部