南宁做网站 的,永久免费企业建站官网大全,12380网站建设情况说明,国家企业信息公示系统官网官说明
此文档主要说明一些常见compaction问题的排查思路和临时处理手段。这些问题包括
Compaction socre高Compaction失败compaction占用资源多Compaction core 如果问题紧急#xff0c;可联系社区同学处理 如果阅读中有问题#xff0c;可以反馈给社区同学。
1 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_idxxxxcompact_typecumulative
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:BaseCompaction:135202205, peak used 1435738416, current used 1164740816, exec node:, process memory used 105.03 GB exceed limit 109.63 GB or sys available memory 11.71 GB less than low water mark 12.18 GB.
no enable stack, _FILE:/home/ec2-user/selectdb-core/be/src/olap/rowset/segment_v2/segment_iterator.cpp, __LINE:2000, __FUNCTION_:auto doris::segment_v2::SegmentIterator::next_batch(vectorized::Block *)::(anonymous class)::operator()() const, tablet135202205.758764227.6e8b36c0cc1b4ac2-9f14bb5b6d058fe6, output_version[2-8237]内存问题又分为以下几种情况
compaction本身占用内存不多BE其他的请求比如导入查询占用了过多的内存导致的compaction偶发失败。单个compaction占用内存多多个compaction占用内存多
对于上述细分的原因需要查看memtracker当前compaction内存使用的情况来定位。 2.1.2 compaction校验失败
if (_input_row_num ! _output_rowset-num_rows() _stats.merged_rows _stats.filtered_rows) {return Status::ErrorCHECK_LINES_ERROR(row_num does not match between cumulative input and output! tablet{}, input_row_num{}, merged_row_num{}, filtered_row_num{}, output_row_num{},_tablet-tablet_id(), _input_row_num, _stats.merged_rows, _stats.filtered_rows,_output_rowset-num_rows());}2.2 处理方式
2.2.1 内存问题
细分原因1compaction本身占用内存不多BE其他的请求比如导入查询占用了过多的内存导致的compaction偶发失败。
本身问题不在compaction可以观察下如何compaction不是持续的失败并且compaction score没有明显的身高可以暂不处理持续观察。
细分原因2单个compaction占用内存多
可以暂时通过限制参与compaction的rowset个数来限制compaction的使用调节BE的cumulative_compaction_max_deltas这个配置值默认是1000
细分原因3多个compaction占用内存多
可以暂时通过限制参与compaction的rowset个数来限制compaction的使用调节BE的cumulative_compaction_max_deltas这个配置值默认是1000 或者
可以通过限制compaction线程的个数来限制内存be对应配置max_base_compaction_threads和max_cumu_compaction_threads
2.2.2 compaction 校验失败
可能是正确性问题需联系社区同学定位处理
3 compaction占用资源多
3.1 compaction占用cpu资源多
top -H 确认是否是compaction线程 处理方式
处理方式1
可以调整做compaction的线程数量
max_base_compaction_threads默认是4 max_cumu_compaction_threads默认每块盘1个处理方式2
可以调整每个盘上compaction的并发数量
如果配置的是HDD盘调整compaction_task_num_per_disk
如果配置的是SSD盘调整compaction_task_num_per_fast_disk
compaction_task_num_per_disk默认是4
compaction_task_num_per_fast_disk默认是8调节完要主要观察compaction score的变化防止出现compaction并发限制的太小导致的compaction score升高的问题
3.2 compaction占用内存资源多
参考第二节关于内存超限导致compaction失败的处理方式
4 compaction导致BE core
分情况处理
偶发一次:
收集be.outBE.infocore dumpbe版本信息包括具体的commit id)判断是否有特殊的操作比如scheam change等操作然后联系社区同学
持续失败:
这种情况可能会影响用户的可用性可以先止损。关掉这个表的compaction
1 先通过导致compaction的tablet id找到表show tablet {tablet_id}命令可以找到表名
2 关闭这个BE的compaction配置BE.conf disable_auto_compaction true
3 关掉这个表的compactionalter table ${tableName} set (“disable_auto_compaction” “true”)
4 打开BE的compaction配置BE.conf disable_auto_compaction false
虽然core在compaction的栈上但是很可能不是compaction的问题因为compaction是一个后台的不断进行的读写线程不断的触发读写。很可能查询也会core只是没有进行查询所以通过compaction暴露了这个问题。对于此类core需要联系社区的同学定位处理。
