【Apache Doris】BE宕機問題排查指南

背景
BE宕機分類
- 如何判斷是BE進程是Crash還是OOM
- BE Crash 后如何排查
- BE OOM 后如何分析
- Cache 沒及時釋放導致BE OOM（2.0.3-rc04）
關于社區

作者｜李淵淵

背景

在實際線上生產環境中，大家可能遇到過BE 宕機的問題，Apache Doris 的BE部分是由C++編寫，當出現一些內存越界，非法訪問的問題時會導致BE進程的Crash，同時也比較難排查，我們通過幾個例子來帶大家一起分析下。同時一般為了減小此類問題對線上業務造成影響，大家都會通過一些特殊方案來避免，比如：

容災備份、讀寫分離、建設兩地三中心等: 跨集群數據同步
手動配置 Service 自動拉起：服務自動拉起 - Apache Doris。服務自動拉起
Manager 接管集群進行服務自動拉起：Doris Manager

BE宕機分類

目前一般遇到的有這么幾種情況：

BE 進程非正常退出
a. 有 bug 導致BE進程Crash
b. BE 進程OOM
BE 進程正常退出
這里我們主要看非正常退出這塊。因為其實有部分情況是這樣的，有些同學和運維同學內部沒有對齊，可能服務器reboot了或者什么情況，所以一般出現問題后，可以先和相關的同學對齊下，看看是否有其他操作。

如何判斷是BE進程是Crash還是OOM

首先可以看be/log/be.out中是否有堆棧信息，如果有堆棧信息輸出就是crash了，如下：
如果沒有堆棧信息，只有一些啟動信息的話，可以通過執行dmesg -T 看看是否是OOM，如果是OOM會有Killed的日志

BE Crash 后如何排查

首先BE core了之后先不要著急，可以先嘗試將服務拉起來（建議配置自動拉起），后續繼續排查。首先觀察堆棧信息，堆棧中有一個 Query id ，這個一般是導致BE core的query
通過 query_id 定位下是哪條sql導致的，需要去fe下fe.audit.log中grep下，注意要去所有FE 節點進行搜索，因為如果是做了負載均衡的話可能是發送到其中一個fe節點執行的，因為查詢這種不涉及元數據操作的sql是不會轉發到master的。比如：grep “58a4a56ad38f4f57-b958cc1374948c85” fe/log/fe.audit.log
定位出是哪條sql導致的，可以先把這條sql禁止掉，同時方便的話可以整理下涉及到的表的schema信息等，把be.out + 整理的信息提供給社區同學，方便復現和定位問題。
等待社區同學進行分析和判斷，同時可以判斷下這個問題的影響面。
a. 如果這個問題比較嚴重，且是未知問題，可以先等社區分析和修復，著急的話可以聯系社區同學提供patch包（patch包沒有經過回歸測試，所以需要評估）。
b. 如果是已知問題，并且在新版本已經修復，那么可以考慮通過升級解決這個問題。

特殊情況：
有時候問題比較難復現，排查問題的周期也會比較長，如果問題比較嚴重，那么對用戶業務的影響面還是比較大的，所以有時需要用戶環境生成的 core 文件來配合進行debug，來盡快的定位和fix問題。下邊介紹下如何取core文件。

1.查看生成CoreDump文件的開關是否開啟，輸入命令 ulimit -a

在這里插入圖片描述

2.第一行 core file size 為0，則不會生成CoreDump。使用 ulimit -c [kbytes] 命令可以設置系統允許生成的CoreDump的文件大小。所以在BE啟動時，加入以下命令即可ulimit -c unlimited -n 65536 && sh start_be.sh --daemon啟動后可以通過 cat /proc/{be pid}/limits 確認是否成功開啟coredump，core file size是 unlimited 則表示已經成功打開。

3.此時，就會在BE Crash的時候，生成CoreDump文件，默認的位置是在BE目錄下，如果BE目錄下沒有core文件嗎，執行以下命令，這里顯示CoreDump文件被core_pattern定義設置在了/tmp目錄下，所以需要到對應的目錄查找BE生成的CoreDump文件。
cat /proc/sys/kernel/core_pattern/tmp/core_%t_%e_%p

在這里插入圖片描述

方便的話可以把core文件進行壓縮上傳到對象存儲上，然后提供給社區同學進行問題的定位和fix

BE OOM 后如何分析

一般大家在使用的過程中會遇到內存泄漏不釋放，或者是因為一些大query和load任務導致OOM的情況，下文帶大家一起實操一把，如何進行分析。首先可以參考官網OOM的分析以及memtracker如何看：

BE OOM分析 - Apache Doris
內存跟蹤器 - Apache Doris

Cache 沒及時釋放導致BE OOM（2.0.3-rc04）

BE 出現宕機，且已經通過dmesg -T 確定是OOM
這時候如果有部署監控，可以通過監控看下具體內存的使用情況
通過BE重啟的時間節點，找到最后一次打印的memtracker的統計信息進行分析
從這個日志中可以詳細的看到各個模塊在內存的使用情況

BE 進程總共使用了209.01 GB
內存中 導入69G，其中 LoadChannelMgr 33G
page cache 46G
jemalloc cache 15G
brpc IOBufBlockMemory 5G
SegCompaction 13G
orphan 77G 
其中應該大部分是 segment cache、tablet schema 等元數據內存

分析： minor gc 只會淘汰過期的cache，full gc才會淘汰所有cache，因為 GC 線程卡住，一直沒到full gc，所以page cache等一直沒釋放，最終導致OOM。

臨時規避方式：

調低 jemalloc purge dirty page 時間，be.conf 中修改 JEMALLOC_CONF，把 dirty_decay_ms:15000 改成 dirty_decay_ms:3000，預期對性能的影響很小。
be.conf 中增加 soft_mem_limit_frac=1，mem_limit=75%，確保只會觸發full gc補充，目前2.0最新的tag，已經將 jemalloc purge dirty page改成異步的了，不會再阻塞gc過程

大查詢導致BE OOM：

通過BE重啟的時間節點，找到最后一次打印的memtracker的統計信息進行分析
從這里memtracker統計信息中能看到query占了156.74 GB
沒cancel完成的query分析
OOM時間點：11:26:04.00
a. 557061ef69164835-91b49a23b5ad2e86，11:25:50.78提交，11:26:00系統內存不足被cancel，

b. 44fe8d21b1bc464e-8b76ebd5616b5a2e, 11:25:50.58提交，11:26:01.53系統內存不足被cancel

c. 21fbdf757857472f-acc7b3019a9cf5c7，11:25:50.62 提交，11:26:02.12系統內存不足被cancel

MemTrackerLimiter Label=Query#Id=557061ef69164835-91b49a23b5ad2e86, Type=query, Limit=2.00 GB(2147483648 B), Used=19.71 GB(21161637576 B), Peak=19.71 GB(21161637576 B)MemTrackerLimiter Label=Query#Id=44fe8d21b1bc464e-8b76ebd5616b5a2e, Type=query, Limit=2.00 GB(2147483648 B), Used=19.48 GB(20918726034 B), Peak=19.48 GB(20918726034 B)MemTrackerLimiter Label=Query#Id=cdab77b22af4838-bf091a81792ce980, Type=query, Limit=2.00 GB(2147483648 B), Used=19.03 GB(20434770852 B), Peak=19.03 GB(20434770852 B)MemTrackerLimiter Label=Query#Id=970a709426054d7c-adb669c4a0149008, Type=query, Limit=2.00 GB(2147483648 B), Used=18.06 GB(19391774018 B), Peak=18.06 GB(19391774018 B)MemTrackerLimiter Label=Query#Id=21fbdf757857472f-acc7b3019a9cf5c7, Type=query, Limit=2.00 GB(2147483648 B), Used=17.97 GB(19289808376 B), Peak=17.97 GB(19289808376 B)MemTrackerLimiter Label=Query#Id=7b588343d6b44405-a6133ba172430450, Type=query, Limit=2.00 GB(2147483648 B), Used=17.63 GB(18927825655 B), Peak=17.63 GB(18927825655 B)MemTrackerLimiter Label=Query#Id=b3d4d075f39f48bd-89ab45378d20a028, Type=query, Limit=2.00 GB(2147483648 B), Used=17.07 GB(18332161696 B), Peak=17.07 GB(18332161696 B)

結論：query cancel不及時導致OOM，情況比較極端：
a. 11:25:50 同一時間提交了10個左右大查詢，每個內存都在10G+
b. 11:26:00 - 11:26:02 GC發現系統內存不足陸續cancel了這10個query，此時系統可用內存只剩3G
c. 11:26:04 BE進程OOM，query沒有cancel完成

目前2.1 版本上目前修復了一些 query cancel 慢的問題

規避方式：

be.conf 中增加 
max_sys_mem_available_low_water_mark_bytes=6871947672   （默認1.6G，改成6.4G或3.2G）

關于社區

在這里插入圖片描述

Apache Doris 是一個基于 MPP 架構的高性能、實時的分析型數據庫，以極速易用的特點被人們所熟知，僅需亞秒級響應時間即可返回海量數據下的查詢結果，不僅可以支持高并發的點查詢場景，也能支持高吞吐的復雜分析場景。
如果您對 Apache Doris 感興趣，可以通過以下入口訪問官方網站、社區論壇、GitHub和dev郵件組：

💡官方文檔

💡社區論壇

💡GitHub

💡dev郵件組：dev@doris.apache.org

非常歡迎您在社區論壇中與其他用戶分享您的使用經驗和技巧，或者向dev郵件組提交反饋和意見。