Doris FE 常见问题与处理指南

数据极客圈

发布于 2025-07-14 17:33:45

42700

代码可运行

运行总次数：0

代码可运行

在数据仓库领域，Apache Doris 凭借其卓越性能与便捷性被广泛应用。其中，FE（Frontend）作为核心组件，承担着接收查询请求、管理元数据等关键任务。然而，在实际使用中，FE 难免会遭遇各类问题，影响系统的正常运行与性能表现。本文将深入剖析 Doris FE 常见问题及其处理办法。

一、定位 FE 问题的关键信息

当 FE 出现问题时，精准定位是解决问题的首要步骤。首先，需关注出问题前后 1 天左右的日志，若为多节点部署，每个节点的相关日志都至关重要。这些日志包括：

fe/log目录下的fe.log（记录 FE 运行的关键事件与错误信息）、fe.audit.log（审计日志，可用于追踪操作记录）、fe.gc.log（垃圾回收日志，对分析内存问题有重要参考价值）以及fe.out（包含fe启动和宕机的相关信息）。
fedoris - metabdbje.info.0（bdbje 日志，其打印时间为 UTC 时间，需注意加上 8 小时转换为北京时间）。
精确到 commit 号的版本信息，可通过执行start_fe.sh --version在控制台输出或fe.out中获取。
show frontends的全部输出，能展示 FE 节点的详细状态信息。
若有 prometheus 监控，还需提供如 jvm heap 堆内存使用情况、线程数量、导入 job 数量、checkpoint 失败次数等监控数据。
当 FE 卡住时，需通过jstack -l $(pid)> jstack txt搜集 jstack 信息；若内存使用高达数十 GB，则需jmap信息。
机器的 cpu、内存、磁盘 io、网络的 promethues 监控情况，排查是否存在 cpu 打满、物理内存耗尽、磁盘 io 秒级延迟、网络丢包等问题。
dmesg -T > dmesg txt信息，常用于定位FE OOM的问题。

二、FE 常见问题解析与应对

（一）FE 挂掉

master 节点写达不成多数派挂

Insufficient acks for policy:SIMPLE_MAJORITY. Need replica acks: 1. Missing replica acks: 1

原因：

内存使用过高，可能是 cms 垃圾回收器遭遇 “promotion failed” 或者 “concurrent mode failure”，此时需排查内存使用情况，可通过jmapdump 内存镜像并用jprofiler进行分析（搞不了的话，可以联系社区同学协助分析）。
多节点环境下，若其他节点状态逻辑错误已死掉，仅剩一个 master 节点，需同时查看其他 fe 节点日志，确认其存活状态与是否有异常退出栈。
某些节点机器的物理资源（cpu、内存、io）存在瓶颈，需查看机器相应监控。
master 因 gc 或者 io 写 io 消耗时间太长，如在je.info.0中出现类似日志

2025 - 03 - 04 01:27:00.165 UTC WARNING [fe_026093bb_658d_41dc_8f8b_96bd5a968c24] FSync time of 106698 ms exceeds limit (5000 ms)” 的日志。

fe 堆内存 OOM

现象与处理：fe.out中会有相应打印，出现该情况需分析 fe jvm 堆内存占用情况。需要在后续内存高的时候dump内存出来，具体分析一下

★几种常见的oom场景见下文 “fe内存问题”

操作系统 oom 杀掉 java 进程

原因：机器上其他进程占据过多内存，致使 fe 无法获取 jvm - Xmx 配置的堆内存，操作系统启动 oom - killer 线程杀掉 fe。

排查方法：通过dmesg -T | grep -i java查看日志信息，

（二）FE 内存问题

堆内存内存高，遇到 gc 降级，master pause 太长时间，导致 fe 挂

场景：尤其在高频导入情况下，事务和 LoadJbb 占内存多，其他 follower 重新选举后，原 master 退出，新接任的 master 节点重复出现该问题。

解决办法：

配置label 保留参数：

label_keep_max_second = 21600 // 6 hour
streaming_label_keep_max_second = 21600  // 6 hour

修改FE JVM 的 gc算法为g1，参考如下

JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false -Xmx8g -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:$LOG_DIR/log/fe.gc.log.$DATE -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=50M -Dlog4j2.formatMsgNoLookups=true"

schema change job 数量多

影响：可能导致 fe com 或者出现上述堆内存高的情况（较新版本有优化）。

误开 profile 或者 profile 功能存在 bug（2.0.2版本之后已经优化了）

cms 垃圾回收器回收不及时

现象：待回收临时对象多，导致内存使用高，遇到 gc 降级 fe 挂，内存使用量监控呈锯齿状，类似下图（同堆内存高问题，新版本改为 g1 回收器）。

（三）FE 启动不起来

meta out of date 或者 wait catalog to be ready

原因：

磁盘空间不足，bdbje 禁止写入，出现 “com.sleepycat je.DiskLimitException” 错误。
meta out of date 偶尔打印一次属正常，可调参数。meta_delay_toleration_second 默认值 300（5 分钟），元数据延迟间隔时间。

★启动时打印少数几次 meta out of date，随后不再打印，也为正常现象。

时钟不同步：

如出现 “Clock delta: xxxx ms.between Feeder” 类似的日志

this Replica exceeds max permissible delta: 5000 ms. HANDSHAKE_ERROR: Error during the handshake between two nodes. Some validity or compatibility check failed, preventing further communication between the nodes

这是节点间时钟不同步，需要校正时钟。

doris fe 代码 bug（序列化 / 反序列化问题 / NullPointerException）等。

已经修复了，修复pr(推荐升级):

https://github.com/apache/doris/pull/26563

https://github.com/apache/doris/pull/30337

https://github.com/apache/doris/pull/30441

doris fe 非主节点写 editlog 导致

类似下图这种，已经修复（推荐升级）：https://github.com/apache/doris/pull/29395

运维操作不当

做了降级操作，高版本的 doris - meta 元数据用低版本的 jar 包启动。比如报错这种（仅供参考）：

Unknown meta module: workloadSchedPolicy

升级操作 jar 替换不全或未清理旧版本 jar 包。比如报错（仅供参考）：

“java.lang.NoSuchMethodError: 'com.google.gson.GsonBuilder com.google.gson.GsonBuilder.addReflectionAccessFilter”

长时间 checkpoint 失败导致重新启动慢

可通过ls doris-meta/image -l查看最近 checkpoint 成功的时间，正常情况下 10 分钟会有一次成功的 checkpoint。

（四）doris - meta/bdb 目录大（几十 GB）

需先检查所有节点状态是否正常，master 近期是否做 checkpoint，内存使用超过 jvm heap 70% 不做 checkpoint（可通过grep -i "checkpoint' fe.log.xxx排查），master 做完 checkpoint 是否 push image 到其他节点成功，是否因 image 过大导致 push image timeout。fe.log里面会有类似日志：

 [Checkpoint.doCheckpoint():210] Failed when pushing image file.

（五）doris - meta/image/image.xxx 文件大（几十 GB）

导入 label 比较多，没有及时删除，可以参考前面的参数进行调整

ccr bin log 占的多：旧版本的ccr默认的 disable binlog 不会清空已经记录的 binlog ，主要还是 ttl_seconds 没有设置，disable 的时候仍然需要依靠 ttl_seconds 来回收。

解决方法：旧版本把之前开过 binlog 的表都设置一下 "binlog.enable" = "true"，再设置 "binlog.ttl_seconds" 为一个合理的值。或者直接升级到最新稳定版本

（六）FE 卡住死锁（jmap dump fe 内存镜像）

1. 高并发点查把 cpu 打满后，连带导致内存高占用：在监控中会呈现 CPU 和内存先后升高的趋势。

2. 内存本身高占用，故障时间点做 checkpoint 需要近 1 倍内存：在fe.log搜索checkpoint关键词，类似下面的日志：

 the memory used percent 73 exceed the checkpoint memory threshold: 70, exceeded count: 1”“2024 - 09 - 06 23:16:14,959 INFO (leader Checkpointer (99) [Checkpoint do Checkpoint () :124] begin to generate new image: image.8745633

3. 大查询解析过程把 fe 打满：表现为 CPU 升高。