說明

此文檔主要說明一些常見compaction問題的排查思路和臨時(shí)處理手段。這些問題包括

• Compaction socre高
• Compaction失敗
• compaction占用資源多
• Compaction core

如果問題緊急，可聯(lián)系社區(qū)同學(xué)處理
如果閱讀中有問題，可以反饋給社區(qū)同學(xué)。

1 compaction score高

找出score最高的若干個(gè)tablet，一般是用戶比較高頻導(dǎo)入的表

分析score最高的tablet形成的原因，以下幾個(gè)為常見的原因

1.1 compaction持續(xù)失敗導(dǎo)致的compaction socre高

判斷方式：
1 grep ${tablet_id} be.INFO | grep compaction，看是否有持續(xù)失敗的日志

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

處理方式：參照第2節(jié)進(jìn)行處理

1.2 用戶使用不當(dāng)

1.2.1 建表時(shí)，bucket數(shù)量設(shè)置的不合適。

設(shè)置的太小，導(dǎo)致的compaction可能不能充分并發(fā)執(zhí)行。

設(shè)置的太多，可能會有比較多的compaction任務(wù)調(diào)度。

建議根據(jù)tablet 1GB - 10GB的最佳實(shí)踐，設(shè)置bucket數(shù)量

其他使用不當(dāng)?shù)姆绞?，待補(bǔ)充…

1.3 compaction策略問題

score很高的tablet，卻很久沒有執(zhí)行過compaction

判斷方式：

1 通過curl ip:port/api/compaction/show?tablet_id=${tablet_id} 查看tablet compaction上一次執(zhí)行的時(shí)間。

2 grep ${tablet_id} be.INFO | grep compaction，看該tablet compaction執(zhí)行的歷史，是否該tablet很長時(shí)間沒有進(jìn)行compaction

處理方式：

1 臨時(shí)處理手段，手動(dòng)觸發(fā)compaction:

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

2 這類問題可能是策略的bug，需要聯(lián)系社區(qū)同學(xué)跟進(jìn)處理，需要以下信息

Compaction score的監(jiān)控

Compaction score從低到高漲上來時(shí)BE的日志

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

1.4 導(dǎo)入速度超過了compaction的速度

這里又分為兩種情況

1.4.1 cpu負(fù)載不高

可能是compaction的并發(fā)不夠，需要調(diào)整下面這些配置（根據(jù)情況修改）

max_base_compaction_threads 默認(rèn)是4
max_cumu_compaction_threads 默認(rèn)是每個(gè)盤1個(gè)
compaction_task_num_per_disk，默認(rèn)是4
compaction_task_num_per_fast_disk，默認(rèn)是8

判斷方式：

1 查看compaction 一段時(shí)間內(nèi)的平均并發(fā)數(shù)

cloud使用這個(gè)命令

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使用這個(gè)命令

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}'

• 用上述的命令統(tǒng)計(jì)一段時(shí)間內(nèi)compaction的總耗時(shí)（注意，cloud統(tǒng)計(jì)出的耗時(shí)單位是毫秒，而社區(qū)統(tǒng)計(jì)出的耗時(shí)單位是秒)。比如耗時(shí)是4000秒
• 計(jì)算統(tǒng)計(jì)的clock time，比如統(tǒng)計(jì)的日志文件包含14:00 到 14:20日志，那clock time = 20min * 60 = 1200秒
• compaction的平均并發(fā) 4000 / 1200 = 3.3 并發(fā)

2 獲取BE的配置的并發(fā)限制和compaction線程數(shù)量，查看BE conf，如果沒有配置則為默認(rèn)
如果實(shí)際的并發(fā)已經(jīng)接近設(shè)置的并發(fā)，則是并發(fā)不足

1.4.2 cpu負(fù)載比較高

處理方式：

1 如果BE的負(fù)載比較高，且用戶的導(dǎo)入比較高頻，看下能否攢批導(dǎo)入，降低導(dǎo)入頻率

2 如果導(dǎo)入頻率也不高，則需要考慮擴(kuò)容

1.5 compaction score持續(xù)升高，導(dǎo)致導(dǎo)入報(bào)-235

這種現(xiàn)象之前出現(xiàn)的比較多，單獨(dú)列出來，這是一個(gè)現(xiàn)象，原因可能還是上述的一種，針對此現(xiàn)象有一個(gè)臨時(shí)的處理手段，如果對報(bào)-235的表沒有頻繁的導(dǎo)入和查詢，可以適當(dāng)調(diào)大max_tablet_version_num。這只是一個(gè)臨時(shí)手段，還是要找到compaction score升高的原因
max_tablet_version_num，默認(rèn)值是2000

2 Compaction 失敗

2.1 定位問題

通過grep compaction be.INFO | grep {tablet_id} 查看compaction失敗的具體原因。
原因包括但不限于，內(nèi)存分配失敗，compaction數(shù)據(jù)校驗(yàn)失敗

2.1.1 內(nèi)存問題

內(nèi)存分配失敗會有類似一下日志

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]

內(nèi)存問題又分為以下幾種情況

• compaction本身占用內(nèi)存不多，BE其他的請求（比如導(dǎo)入，查詢）占用了過多的內(nèi)存，導(dǎo)致的compaction偶發(fā)失敗。
• 單個(gè)compaction占用內(nèi)存多
• 多個(gè)compaction占用內(nèi)存多

對于上述細(xì)分的原因需要查看memtracker，當(dāng)前compaction內(nèi)存使用的情況來定位。

2.1.2 compaction校驗(yàn)失敗

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());
    }

2.2 處理方式

2.2.1 內(nèi)存問題

細(xì)分原因1：compaction本身占用內(nèi)存不多，BE其他的請求（比如導(dǎo)入，查詢）占用了過多的內(nèi)存，導(dǎo)致的compaction偶發(fā)失敗。

本身問題不在compaction，可以觀察下，如何compaction不是持續(xù)的失敗，并且compaction score沒有明顯的身高，可以暫不處理，持續(xù)觀察。

細(xì)分原因2：單個(gè)compaction占用內(nèi)存多

可以暫時(shí)通過限制參與compaction的rowset個(gè)數(shù)來限制compaction的使用，調(diào)節(jié)BE的cumulative_compaction_max_deltas這個(gè)配置值，默認(rèn)是1000

細(xì)分原因3：多個(gè)compaction占用內(nèi)存多

可以暫時(shí)通過限制參與compaction的rowset個(gè)數(shù)來限制compaction的使用，調(diào)節(jié)BE的cumulative_compaction_max_deltas這個(gè)配置值，默認(rèn)是1000
或者：

可以通過限制compaction線程的個(gè)數(shù)來限制內(nèi)存，be對應(yīng)配置，max_base_compaction_threads和max_cumu_compaction_threads

2.2.2 compaction 校驗(yàn)失敗

可能是正確性問題，需聯(lián)系社區(qū)同學(xué)定位處理

3 compaction占用資源多

3.1 compaction占用cpu資源多

top -H 確認(rèn)是否是compaction線程

處理方式

處理方式1

可以調(diào)整做compaction的線程數(shù)量

max_base_compaction_threads，默認(rèn)是4 
 max_cumu_compaction_threads，默認(rèn)每塊盤1個(gè)

處理方式2

可以調(diào)整每個(gè)盤上compaction的并發(fā)數(shù)量

如果配置的是HDD盤，調(diào)整compaction_task_num_per_disk，
如果配置的是SSD盤，調(diào)整compaction_task_num_per_fast_disk
compaction_task_num_per_disk，默認(rèn)是4
compaction_task_num_per_fast_disk，默認(rèn)是8

調(diào)節(jié)完，要主要觀察compaction score的變化，防止出現(xiàn)compaction并發(fā)限制的太小，導(dǎo)致的compaction score升高的問題

3.2 compaction占用內(nèi)存資源多

參考第二節(jié)關(guān)于內(nèi)存超限導(dǎo)致compaction失敗的處理方式

4 compaction導(dǎo)致BE core

分情況處理

偶發(fā)一次:

收集be.out，BE.info，core dump，be版本信息（包括具體的commit id)，判斷是否有特殊的操作，比如scheam change等操作，然后聯(lián)系社區(qū)同學(xué)

持續(xù)失敗:

這種情況可能會影響用戶的可用性，可以先止損。關(guān)掉這個(gè)表的compaction

1 先通過導(dǎo)致compaction的tablet id找到表，show tablet {tablet_id}命令可以找到表名

2 關(guān)閉這個(gè)BE的compaction，配置BE.conf disable_auto_compaction = true

3 關(guān)掉這個(gè)表的compaction，alter table ${tableName} set (“disable_auto_compaction” = “true”)

4 打開BE的compaction，配置BE.conf disable_auto_compaction = false

雖然core在compaction的棧上，但是很可能不是compaction的問題，因?yàn)閏ompaction是一個(gè)后臺的不斷進(jìn)行的讀寫線程，不斷的觸發(fā)讀寫。很可能查詢也會core，只是沒有進(jìn)行查詢，所以通過compaction暴露了這個(gè)問題。對于此類core，需要聯(lián)系社區(qū)的同學(xué)定位處理。

到此這篇關(guān)于Apache Doris 中Compaction問題分析和典型案例的文章就介紹到這了,更多相關(guān)Apache Doris 中Compaction內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論