Apache Doris BE 常见问题定位处理

Apache Doris 经验手册
1

针对大家在使用 Doris 过程中，特别是 BE 出现问题的情况下，大家不知道从下手进行分析，同时也不知道给提供哪些信息给社区开发人员进行定位分析，这样无形之间加大了之间的沟通成本，下面详细展开说下遇到常见的几类问题我们应该怎么做。

1. Doris BE 挂掉

BE挂掉，从大面上看，一般有两种原因

1.1 最常见的是OOM KILLER杀掉了BE进程

针对这种 OOM 情况，我们可以通过 dmesg -T 来查看系统日志，确认是不是因为内存 OOM ，导致 be 进程被 KILL。

dmesg -T | less

#可以看到对应的doris_be 有Out of memory error log, RSS即是当时被KILL时BE进程实际占的内存
#请一定要核对好下面的时间和BE的时间是否一致

[Fri Sep 2 22:58:19 2022] Out of memory: Killed process 1332190 (doris_be) total-vm:21484964304kB, anon-rss:91048156kB, file-rss:1484kB, shmem-rss:0kB, UID:0 pgtables:225764kB oom_score_adj:0
[Fri Sep 2 22:58:22 2022] oom_reaper: reaped process 1332190 (doris_be), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

如果是这种原因，是因为BE没有保护好自己，这个使命是由 memtracker 来实现的，即控制查询的内存，使得BE总体进程内存不超过用户配置的 mem_limit（默认为80%），这样不触发系统的 OOM KILLER 杀BE。

如果用户短期内就是遇到这个问题，可以适当的在 be 的 conf/be.conf 中，增加一条显式的降低最大内存使用来降低触发概率，长期要靠Memtracker 来彻底的保护。

mem_limit=60%
#配置该项到be的be.conf中并重启BE后生效

1.2 BE Core Dump

这种情况下，be.out会有对应的栈。

我们首先要查看 be.out 日志文件，然后通过这个日志文件中的堆栈信息，来联系社区人员进行定位分析处理

在 1.1.5 及之后的版本，我们在堆栈信息中打印了因为be core的 SQL query id ，这样我们就可以通过这个 query id 去 fe 的fe.audit.log 中找到对应的SQL及这个SQL 对应的建表语句，联系社区开发人员进行快读复现定位处理，

注意：

这里很多用户是从之前版本升级上来，因为之前版本的向量化存在一些问题，用户显示的关闭的向量化引擎，这里我们可以先进行一下打开向量化进行尝试：

mysql> show variables like ‘%vec%’;
±-------------------------±------+
| Variable_name | Value |
±-------------------------±------+
| enable_vectorized_engine | true |
±-------------------------±------+
mysql> set [global] enable_vectorized_engine = true;

打开这个向量化引擎之后，在确认是否还会出现 be core 的情况。

特别是 1.1.5 及 1.2 版本一定要默认打开向量化引擎，这两个版本向量化已经非常完善，而且后面我们已经开始删除非向量化版本的代码，一定要打开向量化引擎这个参数。

针对1.1.5 之前版本在 be.out 里没有记录 query id 的，请参照下面这个文章打开 linux core dump ，进行定位 SQL，上面的的情况，可能到时候也会需要按照下面文章打开 core ，拿到 core 文件以方便开发人员定位处理。

Doris开发手记：利用CoreDump文件快速定位Doris的查询问题

没有 coredump 文件只靠be.out 打印出来的信息也有可能定位 query_id 具体操作方法：

  1. 在be.out 里找到产生coredump 的TID (Thread ID) ** SIGSEGV (@0x0) received by PID 31685 (TID 0x7f921416c700))
  2. 将16进制的thread id 转成 10 进制 [linux-terminal] printf “%d\n” 0x7f921416c700 140265378989824
  3. 在be INFO 里grep 10进制的thread id [linux-terminal] grep 140265378989824 be.INFO，拿到query_id I1019 16:57:26.899314 260721 fragment_mgr.cpp:441] _exec_actual(): query_id=xxxxx-xxxx fragment_instance_id=xxxx-xxxxxx thread id by pthread_self()= 140265378989824
  4. 去FE 审计日志里grep query_id 找到对应的sql

当我们已经知道是什么SQL导致的出CORE后，我们要尝试是不是一些新功能导致的，通过改变一些当前的状态来尝试是否还触发BE CORE，当前涉及的配置主要是：

session variables

set [global] enable_vectorized_engine = false # default is true

be.conf need to reboot，低基数字典

enable_low_cardinality_optimize = false #需要看看是否有相关的线索，不用盲目尝试

如果上面还是无法解决，或者改变参数后就可以，请提供以下信息：

  1. 触发 core 的SQL
  2. 问题栈
  3. core 文件
  4. 触发 core 的SQL 涉及表的 Schema

2. BE 内存飙升的问题

在1.1.2 中因为向量化，相对以前版本内存使用的更多，可以适当修改BE的以下几个参数，减少缓存的使用:

chunk_reserved_bytes_limit=2%
buffer_pool_limit=2%
storage_page_cache_limit=4%
max_base_compaction_threads=2

如果问题依然存在，请记录Issues，将各种信息放在Issues中，方便开发人员定位处理

3. Tablet 相关问题

tablet 相关问题，可以参照下面的文章进行排查处理

Apache Doris tablet 副本修复的原理、流程及问题定位

Doris 运维篇：Apache Doris 如何定位处理有问题的Tablet

2 个赞