目录
阐明此文档主要阐明一些常见compaction问题的排查思路和临时处置惩罚手段。这些问题包括
假如问题告急，可联系社区同砚处置惩罚 1 compaction score高找出score最高的若干个tablet，一般是用户比较高频导入的表 分析score最高的tablet形成的缘故原由，以下几个为常见的缘故原由 1.1 compaction连续失败导致的compaction socre高判断方式：
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数目 [code]其他使用不妥的方式，待增补…[/code]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的并发不够，需要调整下面这些设置（根据环境修改） [code]max_base_compaction_threads 默认是4 max_cumu_compaction_threads 默认是每个盘1个 compaction_task_num_per_disk，默认是4 compaction_task_num_per_fast_disk，默认是8[/code]判断方式： 1 查看compaction 一段时间内的匀称并发数 cloud使用这个下令 [code]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}'[/code]开源doris使用这个下令 [code]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}'[/code]
2 获取BE的设置的并发限定和compaction线程数目，查看BE conf，假如没有设置则为默认 1.4.2 cpu负载比较高处置惩罚方式： 1 假如BE的负载比较高，且用户的导入比较高频，看下能否攒批导入，降低导入频率 2 假如导入频率也不高，则需要考虑扩容 1.5 compaction score连续升高，导致导入报-235这种现象之前出现的比较多，单独列出来，这是一个现象，缘故原由可能还是上述的一种，针对此现象有一个临时的处置惩罚手段，假如对报-235的表没有频仍的导入和查询，可以适当调大max_tablet_version_num。这只是一个临时手段，还是要找到compaction score升高的缘故原由 2 Compaction 失败2.1 定位问题通过grep compaction be.INFO | grep {tablet_id} 查看compaction失败的具体缘故原由。 2.1.1 内存问题内存分配失败会有类似一下日记 [code]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, tablet=135202205.758764227.6e8b36c0cc1b4ac2-9f14bb5b6d058fe6, output_version=[2-8237][/code]内存问题又分为以下几种环境
对于上述细分的缘故原由需要查看memtracker，当前compaction内存使用的环境来定位。
2.1.2 compaction校验失败[code]if (_input_row_num != _output_rowset->num_rows() + _stats.merged_rows + _stats.filtered_rows) { return Status::Error<CHECK_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()); }[/code]2.2 处置惩罚方式2.2.1 内存问题细分缘故原由1：compaction自己占用内存不多，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的线程数目 [code]max_base_compaction_threads，默认是4 max_cumu_compaction_threads，默认每块盘1个[/code]处置惩罚方式2 可以调整每个盘上compaction的并发数目 [code]假如设置的是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[/code]调治完，要主要观察compaction score的变革，防止出现compaction并发限定的太小，导致的compaction score升高的问题 3.2 compaction占用内存资源多参考第二节关于内存超限导致compaction失败的处置惩罚方式 4 compaction导致BE core分环境处置惩罚 偶发一次: 收集be.out，BE.info，core dump，be版本信息（包括具体的commit id)，判断是否有特别的操作，比如scheam change等操作，然后联系社区同砚 连续失败: 这种环境可能会影响用户的可用性，可以先止损。关掉这个表的compaction 1 先通过导致compaction的tablet id找到表，show tablet {tablet_id}下令可以找到表名 2 关闭这个BE的compaction，设置BE.conf disable_auto_compaction = true 3 关掉这个表的compaction，alter table ${tableName} set (“disable_auto_compaction” = “true”) 4 打开BE的compaction，设置BE.conf disable_auto_compaction = false 虽然core在compaction的栈上，但是很可能不是compaction的问题，因为compaction是一个背景的不断举行的读写线程，不断的触发读写。很可能查询也会core，只是没有举行查询，以是通过compaction袒露了这个问题。对于此类core，需要联系社区的同砚定位处置惩罚。 到此这篇关于Apache Doris 中Compaction问题分析和典范案例的文章就先容到这了,更多相干Apache Doris 中Compaction内容请搜索脚本之家从前的文章或继续欣赏下面的相干文章盼望大家以后多多支持脚本之家！ 来源：https://www.jb51.net/server/326208u84.htm 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
/6 
|手机版|小黑屋|梦想之都-俊月星空
( 粤ICP备18056059号 )|网站地图
GMT+8, 2025-7-1 18:59 , Processed in 0.030719 second(s), 19 queries .
Powered by Mxzdjyxk! X3.5
© 2001-2025 Discuz! Team.
