說明

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

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

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

1 compaction score高

找出score最高的若干個tablet，一般是用戶比較高頻導入的表

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

1.1 compaction持續(xù)失敗導致的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é)進行處理

1.2 用戶使用不當

1.2.1 建表時，bucket數量設置的不合適。

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

設置的太多，可能會有比較多的compaction任務調度。

建議根據tablet 1GB - 10GB的最佳實踐，設置bucket數量

其他使用不當的方式，待補充…

1.3 compaction策略問題

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

判斷方式：

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

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

處理方式：

1 臨時處理手段，手動觸發(fā)compaction:

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

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

Compaction score的監(jiān)控

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的并發(fā)不夠，需要調整下面這些配置（根據情況修改）

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 一段時間內的平均并發(fā)數

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

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

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

1.4.2 cpu負載比較高

處理方式：

1 如果BE的負載比較高，且用戶的導入比較高頻，看下能否攢批導入，降低導入頻率

2 如果導入頻率也不高，則需要考慮擴容

1.5 compaction score持續(xù)升高，導致導入報-235

這種現(xiàn)象之前出現(xiàn)的比較多，單獨列出來，這是一個現(xiàn)象，原因可能還是上述的一種，針對此現(xiàn)象有一個臨時的處理手段，如果對報-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, tablet=135202205.758764227.6e8b36c0cc1b4ac2-9f14bb5b6d058fe6, output_version=[2-8237]

內存問題又分為以下幾種情況

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

對于上述細分的原因需要查看memtracker，當前compaction內存使用的情況來定位。

2.1.2 compaction校驗失敗

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 內存問題

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

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

細分原因2：單個compaction占用內存多

可以暫時通過限制參與compaction的rowset個數來限制compaction的使用，調節(jié)BE的cumulative_compaction_max_deltas這個配置值，默認是1000

細分原因3：多個compaction占用內存多

可以暫時通過限制參與compaction的rowset個數來限制compaction的使用，調節(jié)BE的cumulative_compaction_max_deltas這個配置值，默認是1000
或者：

可以通過限制compaction線程的個數來限制內存，be對應配置，max_base_compaction_threads和max_cumu_compaction_threads

2.2.2 compaction 校驗失敗

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

3 compaction占用資源多

3.1 compaction占用cpu資源多

top -H 確認是否是compaction線程

處理方式

處理方式1

可以調整做compaction的線程數量

max_base_compaction_threads，默認是4 
 max_cumu_compaction_threads，默認每塊盤1個

處理方式2

可以調整每個盤上compaction的并發(fā)數量

如果配置的是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

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

3.2 compaction占用內存資源多

參考第二節(jié)關于內存超限導致compaction失敗的處理方式

4 compaction導致BE core

分情況處理

偶發(fā)一次:

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

持續(xù)失敗:

這種情況可能會影響用戶的可用性，可以先止損。關掉這個表的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是一個后臺的不斷進行的讀寫線程，不斷的觸發(fā)讀寫。很可能查詢也會core，只是沒有進行查詢，所以通過compaction暴露了這個問題。對于此類core，需要聯(lián)系社區(qū)的同學定位處理。

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

最新評論