odc归档作业被自动取消

OceanBase 技术问题
,
#1

【 使用环境 】生产环境
【 OB or 其他组件 】odc

  1. 列表条目

【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

见附近日志

版本号：4.4.0-1757906289000

Server: 4.4.0-20250916
Release Date: 2025-09-16

1 个赞
#3
  1. 提供下ODC server 端日志 ，包含 2026-10-08 11:53–11:56

2.metadb查一下

select id, status, status_description, cancelling_time, executor_identifier, executor_destroyed_time
from job_job where id in (select job_id from schedule_task where id=18418);  -- 看 status_description 是 "job heartbeat timeout" 还是空

select status, result_json from schedule_task where id=18418;

  1. 执行器侧：${odc.log.directory}/task/18430/executor.log（框架日志，确认有无 “Task timeout, try stop”）；宿主机 dmesg -T | grep -i oom 排除 OOM killer。

  2. 核对调度 10023 的参数里 timeoutMillis （数据归档配置的超时时间）设了多短——若确实很短，循环的根因就是它

2 个赞
#4

这个参数是哪里看 我作业本身没有设置超时时间 而且我也不太可能几十秒就超时

2 个赞
#5 
grep -n -iE "Terminating due|OutOfMemoryError|SIGSEGV" /var/lib/docker/overlay2/18e7bc0fa35d0e78599cc5006a18cd1df1b82e42de27c04cba21ef790cd8e336/merged/opt/odc/process-call.log  | tail -30
7743:Terminating due to java.lang.OutOfMemoryError: Java heap space
7745:Terminating due to java.lang.OutOfMemoryError: Java heap space
7750:Terminating due to java.lang.OutOfMemoryError: Java heap space
8206:Terminating due to java.lang.OutOfMemoryError: Java heap space
8208:Terminating due to java.lang.OutOfMemoryError: Java heap space
8211:Terminating due to java.lang.OutOfMemoryError: Java heap space
8216:Terminating due to java.lang.OutOfMemoryError: Java heap space
8255:Terminating due to java.lang.OutOfMemoryError: Java heap space
8258:Terminating due to java.lang.OutOfMemoryError: Java heap space
8260:Terminating due to java.lang.OutOfMemoryError: Java heap space
8290:Terminating due to java.lang.OutOfMemoryError: Java heap space

归档调度 10023 “已取消” = 执行器堆 OOM

结论

归档任务按 batch_size=10000 行/批 搬运一张每行约 100KB 的大字段表，单批驻留 ≈1GB，正好打满执行器 JVM 的 1GB 堆；JVM 因 -XX:+ExitOnOutOfMemoryError 静默自退，心跳 300 秒超时后任务判 FAILED，界面显示"已取消"。修复=把 dlm_config_limiter_configuration 的 batch_size 降到 2000（下次触发即生效）。

现象（集群输出）

  • 调度 10023：归档 plan_order_record，条件 create_time > '2026-01-01' AND < '2026-08-01'，源/目标同集群
  • 任务 18430 界面"已取消"；metadb 实际 FAILED，原因 “Heart timeout and set job to status FAILED.”
  • 容器 3c399c0536ef：内存限 10GB、现用 ~2GB；宿主机 15GB / 可用 9GB
  • 把条件缩到 1 个月后，断点续跑成功

修复方案

-- 1) 存量（一条 SQL，先查后改）
SELECT batch_size, COUNT(*) FROM dlm_config_limiter_configuration GROUP BY batch_size;
UPDATE dlm_config_limiter_configuration SET batch_size = 2000 WHERE batch_size > 2000;
-- 对小行表无损：批体积仍小，吞吐由 row_limit 封顶不变

-- 2) 增量兜底：产品修复前每日巡检同一条 UPDATE（新建调度仍会被前端带 10000，无全局开关）
-- 3) 可选加堆
-- metadb config_system_configuration
UPDATE config_system_configuration SET value = '2048'
WHERE key IN ('odc.task-framework.job-process-max-memory-size-in-mb',
              'odc.task-framework.job-process-min-memory-size-in-mb');

为什么缩短窗口能跑通（含保留）

缩窗口不是"总匹配行数变少"（1 个月也有 10 万行匹配，远超 10000），而是扫描流里命中密度变稀——每段 1 万主键只 ~1/7 行命中 → 单批 ~140MB；6 个月窗口密度 ~6/7 → 单批 ~860MB-1GB → 炸。

保留：这只在匹配行散布于主键序时成立；若按时间顺序写入（自增主键段连续），扫进哪个窗口都是满批，缩窗口救不了。1 个月能跑通本身反推数据大概率是散布的（待验证）。修复不依赖该假设——这正是不能只靠"缩短时间范围"当修复的原因。

1 个赞