Doris BE 周期性重启：不是内存不够，是 RScan 把 PID 打满了

系列：《Cloud GIDO 三产品特性深讲》加餐 · 场记第 1 篇 标签：Doris、存算分离、线程泄漏、K8s、pids.max、排障

开篇：组件齐了，BE 照样「周期性消失」

Cloud GIDO 跑在 Kafka / Flink / Doris / K8s 之上。运行时再强，底座也会出「看起来像内存、其实不是」的故障。

很常见的现场：

真正要命的日志往往只有一行：

Could not create thread. (error 11) Resource temporarily unavailable
Thread pool routine_load failed to create thread

这篇按真实排查顺序写：痛点 → 证据 → 纠偏 → 根因 → 分层治理。 环境参考：Doris BE 3.1.4（Cloud / Storage Vault / S3）、K8s、pids.max ≈ 37776。 配图已脱敏：数据源 / 集群 / namespace / pod 标签均已打码或裁掉，勿使用未打码原图发文。

现象：重启曲线是「锯齿」，不是偶发尖峰

时间线通常是：

图上要点：

• 斜率近似直线 → 更像「创建不回收」，不像随负载抖动

• 每条线顶在 ~38k，与 pids.max≈37776 吻合

• 多条线错开爬升：重启会换 container id，图例会变多

结论先行：不是 OOM，加内存挡不住。

error 11：先查 PID，不是先加内存

pthread_create 返回 EAGAIN（error 11），常见上限：

限制

典型来源

怎么看

重启后进容器，常见是「掉下来之后」的稳态：

cat /sys/fs/cgroup/pids.max # ≈ 37776
cat /sys/fs/cgroup/pids.current # 几千～一万多
ulimit -u # unlimited
sysctl kernel.pid_max # 很大，不是瓶颈

崩溃前是否贴顶，必须看监控历史（夜莺 / Grafana / Prometheus），不能只看重启后的 pids.current。

用监控钉死「直接死因」

PromQL（脱敏示例）：

container_threads{
namespace="<ns>",
pod=~"doris-be-.*",
container="compute"
}

只认 container="compute"、镜像为 doris-be 的那条。

观察

数值

含义

因果链：

线程打满 pids.max → 再建线程 EAGAIN → abort 重启

24 小时窗口同样是锯齿：

坑：日志写 Routine Load ≠ RL 是主因

崩溃栈落在 RL，容易误判：「增量也不大，怎么打挂？」

拆两层：

角色

含义

要回答「谁占线程」，必须对还活着、正在上涨的 BE 做线程名采样，不能只看 abort 栈。

关键一招：按线程名聚合

PID=$(pidof doris_be)

echo "PID=$PID total=$(ls /proc/$PID/task | wc -l) time=$(date -u +%H:%M:%S)"

for t in /proc/$PID/task/*/comm; do cat "$t"; done 2>/dev/null \\
| sort | uniq -c | sort -rn | head -40

早期采样示例：

线程名

数量

说明

水位更高时（total≈25377）：

项

值

再对照 BE metrics：

curl -s http://127.0.0.1:8040/metrics \\
| grep -E 'doris_be_thread_pool_active_threads|doris_be_routine_load_task_count' \\
| grep -E 'RScan|routine_load'

对比很扎心：

• 指标里 RScan_normal：max=512，active=0

• 系统里却有 两万多个 同名线程

不是扫描真的需要两万线程，而是泄漏：创建了不回收。 RL 只是贴顶后再 pthread_create 失败的那一棒。

根因

维度

结论

一句话：

RScan_normal 线程泄漏 → 贴满 pids.max → EAGAIN → BE abort。

处理分层：止血 / 告警 / 治本

止血

• PAUSE 重复 / 非必要 Routine Load

• 降低大宽表 INSERT…SELECT 频率（现场曾把 ADS 宽表从 1 分钟改为 10 分钟，爬升斜率明显变缓）

• 必要时滚动重启泄漏严重的 BE（治标）

• 评估提高 podPidsLimit / pids.max（如 65536）

降频能「减速」，说明宽表/扫云会加速泄漏；曲线仍可能爬到 ~38k → 治本还得解决 RScan 不回收。

告警

pids.max≈37776 时，日常可能就在 1.7万～2.5万。建议：

级别

阈值

持续

max by (pod) (
container_threads{
namespace="<ns>",
pod=~"doris-be-.*",
container="compute"
}
)

以后若提高 pids.max，按 66% / 85% / 93% 同比调整。

治本

• 收敛并发扫云表 / 宽表加工

• 核对 remote scan / scanner 相关上限

• 对照 Doris 版本是否有 Remote Scan 线程泄漏补丁

• RScan_normal 线程采样与 container_threads 叠图

社区公开 Issue（本来就在公网，可直接引用）：

• apache/doris#66997 [Bug][Cloud] RScan_normal ThreadPool idle workers never shrink; OS threads grow far beyond max_threads=512

排障清单

容器内

cat /sys/fs/cgroup/pids.max
cat /sys/fs/cgroup/pids.current
ulimit -u

PID=$(pidof doris_be)
ls /proc/$PID/task | wc -l
for t in /proc/$PID/task/*/comm; do cat "$t"; done 2>/dev/null \\
| sort | uniq -c | sort -rn | head -40

curl -s http://127.0.0.1:8040/metrics \\
| grep 'doris_be_thread_pool_active_threads' \\
| grep -v '} 0$' | sort -t' ' -k2 -nr | head -20

监控

container_threads{namespace="<ns>",pod=~"doris-be-.*",container="compute"}
container_memory_working_set_bytes{namespace="<ns>",pod=~"doris-be-.*",container="compute"}

FE

SHOW BACKENDS\\G
SHOW ROUTINE LOAD\\G
SHOW PROCESSLIST;

经验教训

排查叙事可记成：

表象（重启）→ 误判（内存 / RL）→ 证据（pids.max + 夜莺锯齿）→ 纠偏（线程名采样）→ 根因（RScan 泄漏）→ 分层治理

今日小结

底座组件「齐了」不等于不会踩坑。Doris Cloud / 存算分离场景下，RScan_normal 这类远端扫描路径一旦泄漏，会先打满容器 PID，再以「很像 OOM / 很像 RL」的样子把 BE 打挂。

对跑 GIDO 批加工、宽表 INSERT…SELECT、扫云表的团队：监控里请把 container_threads 和线程名采样当成一等公民，别只盯内存曲线。

讨论：

延伸

• 系列总览：Cloud GIDO | Open Infrastructure for Data, Governance & Risk

• Apache Doris 文档 / Issue（Remote Scan / Cloud）