OBCE 4.2.5.2 内存分配报错 -4013 问题原因分析

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OceanBase 社区版
【 使用版本 】4.2.5.2-102010012025022610
【问题描述】OBServer 里经常有内存分配报错的日志。
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

【告警信息】

告警概述：alarm_template_id=0:ob_cluster=obrs-1711351485:host=10.*.*.36 OBServer alloc_oops

告警详情：[OBServer alloc_oops] 集群：obrs，主机：10.*.*.36，日志类型：observer，日志文件：/home/admin/oceanbase/log/observer.log，日志级别：WARN，关键字=alloc.*OOPS，错误码=4013，日志详情=[2025-06-12 09:04:25.985509] WARN [LIB] common_realloc (ob_tenant_ctx_allocator.cpp:544) [56524][T1042_TBalance][T1042][YB420A0A0A24-000631AF9255FE24-0-0] [lt=47][errcode=-4013] [OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)。

查看节点 日志，能看到信息也不多。

[2025-04-12 22:09:26.831448] WARN  [LIB] common_realloc (ob_tenant_ctx_allocator.cpp:544) [56524][T1042_TBalance][T1042][YB420A0A0A24-000631AF9255F7C6-0-0] [lt=49][errcode=-4013] [OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)
[52651]OB_MALLOC COST TOO MUCH TIME, cost_time=320179, tenant_id=1008, label=LSMetaFile, ctx_id=0, prio=0, size=2101248, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=320174], seq:[0]
[53788]OB_MALLOC COST TOO MUCH TIME, cost_time=294202, tenant_id=1014, label=LSMetaFile, ctx_id=0, prio=0, size=2101248, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=294198], seq:[0]
[54287]OB_MALLOC COST TOO MUCH TIME, cost_time=387501, tenant_id=500, label=ObFuture, ctx_id=0, prio=0, size=216, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=387498], seq:[0]
[2025-04-12 23:03:35.901777] WARN  [LIB] common_realloc (ob_tenant_ctx_allocator.cpp:544) [56524][T1042_TBalance][T1042][YB420A0A0A24-000631AF9255F7C7-0-0] [lt=50][errcode=-4013] [OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)
[53080]OB_MALLOC COST TOO MUCH TIME, cost_time=849401, tenant_id=500, label=ObFuture, ctx_id=0, prio=0, size=216, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=849399], seq:[0]
[2025-04-12 23:55:21.355684] WARN  [LIB] common_realloc (ob_tenant_ctx_allocator.cpp:544) [56524][T1042_TBalance][T1042][YB420A0A0A24-000631AF9255F7C8-0-0] [lt=48][errcode=-4013] [OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)
[53833]OB_MALLOC COST TOO MUCH TIME, cost_time=849860, tenant_id=500, label=ObFuture, ctx_id=0, prio=0, size=216, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=849858], seq:[0]
[2025-04-13 00:48:08.643299] WARN  [LIB] common_realloc (ob_tenant_ctx_allocator.cpp:544) [56524][T1042_TBalance][T1042][YB420A0A0A24-000631AF9255F7C9-0-0] [lt=51][errcode=-4013] [OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)
[54193]OB_MALLOC COST TOO MUCH TIME, cost_time=370258, tenant_id=1016, label=LSMetaFile, ctx_id=0, prio=0, size=2101248, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=370255], seq:[0]
[51985]OB_MALLOC COST TOO MUCH TIME, cost_time=824787, tenant_id=1015, label=CoStack, ctx_id=8, prio=1, size=515136, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=824780], seq:[0]
[53411]OB_MALLOC COST TOO MUCH TIME, cost_time=384376, tenant_id=1012, label=LSMetaFile, ctx_id=0, prio=0, size=2101248, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=384372], seq:[0]
[55931]OB_MALLOC COST TOO MUCH TIME, cost_time=416621, tenant_id=500, label=ObFuture, ctx_id=0, prio=0, size=216, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=416619], seq:[0]
[53439]OB_MALLOC COST TOO MUCH TIME, cost_time=160369, tenant_id=1012, label=SqcHandlerParam, ctx_id=0, prio=0, size=3976248, owner: ObMalloc, click_count: 1, time dist:[ALLOC_CHUNK_END=1], seq:[0]
2 个赞
#3

根因分析场景: 内存问题
根因分析命令: 无（当前 obdiag 工具未提供针对内存分配错误的特定根因分析场景）
日志采集场景: 内存问题
日志采集命令: obdiag gather scene run --scene=observer.memory

为了更好地帮助您定位和解决问题，建议您使用上述 obdiag 命令采集相关日志并提供给我们。此命令将收集与内存相关的诊断信息，有助于我们深入分析 OBServer 内存分配报错 -4013 的原因。

另外，为了进一步确认问题的具体情况，请您提供以下信息：

  1. 当前 OBServer 的配置文件中关于内存限制的相关参数设置（如 memory_limit 和 memory_limit_percentage），是否进行了自定义调整？
  2. 报错发生时，系统的总内存使用率是多少？可以通过操作系统命令（如 free -m 或 top）获取相关信息。
  3. 是否有大查询或批量操作在报错前后运行？如果有，请提供这些 SQL 的执行计划或概要信息。
  4. 报错日志中是否有其他伴随信息，例如系统资源耗尽的提示或其他异常？
  5. OceanBase 集群的负载情况如何？是否处于高负载状态？

请按照上述步骤操作，并将采集到的日志压缩包上传或发送给我们，以便进一步分析和解决您的问题。

附上敏捷诊断工具 obdiag 使用帮助链接

2 个赞
#4

看下是否为做分区均衡时候抛出的错误

1 个赞
#5 
MySQL [oceanbase]> select * from oceanbase.CDB_OB_BALANCE_JOBS where tenant_id=1042 order by create_time desc limit 10\G
*************************** 1. row ***************************
              TENANT_ID: 1042
                 JOB_ID: 4134532199
            CREATE_TIME: 2025-05-22 12:17:20.555682
            MODIFY_TIME: 2025-05-22 12:17:20.555682
       BALANCE_STRATEGY: intergroup partition count balance
               JOB_TYPE: PARTITION_BALANCE
        TARGET_UNIT_NUM: 1
TARGET_PRIMARY_ZONE_NUM: 3
                 STATUS: DOING
                COMMENT: NULL
           MAX_END_TIME: NULL
1 row in set (0.00 sec)

有个均衡的作业还在运行中（DOING)，看时间是 20天前，这个应该是有问题的。

MySQL [oceanbase]> select * from oceanbase.CDB_OB_BALANCE_JOB_HISTORY where tenant_id=1042 order by create_time desc limit 2\G
*************************** 1. row ***************************
              TENANT_ID: 1042
                 JOB_ID: 4115707486
            CREATE_TIME: 2025-04-12 21:17:42.094361
            FINISH_TIME: 2025-05-22 12:17:20.335410
       BALANCE_STRATEGY: intergroup partition count balance
               JOB_TYPE: PARTITION_BALANCE
        TARGET_UNIT_NUM: 1
TARGET_PRIMARY_ZONE_NUM: 3
                 STATUS: CANCELED
                COMMENT: Canceled because partition schema changed during job
           MAX_END_TIME: NULL
*************************** 2. row ***************************
              TENANT_ID: 1042
                 JOB_ID: 4115703284
            CREATE_TIME: 2025-04-12 21:00:00.947199
            FINISH_TIME: 2025-04-12 21:03:11.095793
       BALANCE_STRATEGY: LS balance by expand
               JOB_TYPE: LS_BALANCE
        TARGET_UNIT_NUM: 1
TARGET_PRIMARY_ZONE_NUM: 3
                 STATUS: COMPLETED
                COMMENT: NULL
           MAX_END_TIME: NULL
2 rows in set (0.01 sec)

历史作业里有个更早的 均衡任务，取消状态。

再查看当前均衡任务细节.

MySQL [oceanbase]> select * from oceanbase.CDB_OB_BALANCE_TASKS
    -> where tenant_id=1042 and job_Id=4134532199\G
Empty set (0.06 sec)

MySQL [oceanbase]> select * from oceanbase.CDB_OB_BALANCE_TASK_HISTORY
    -> where tenant_id=1042 and job_Id=4134532199\G
*************************** 1. row ***************************
               TENANT_ID: 1042
                 TASK_ID: 4134532200
             CREATE_TIME: 2025-05-22 12:17:20.557013
             FINISH_TIME: 2025-05-22 12:17:34.601336
               TASK_TYPE: LS_TRANSFER
                  SRC_LS: 1001
                 DEST_LS: 1004
               PART_LIST: NULL
      FINISHED_PART_LIST: 513772:513772
              PART_COUNT: 0
     FINISHED_PART_COUNT: 1
             LS_GROUP_ID: 1001
                  STATUS: COMPLETED
             PARENT_LIST: NULL
              CHILD_LIST: NULL
CURRENT_TRANSFER_TASK_ID: -1
                  JOB_ID: 4134532199
                 COMMENT: NULL
        BALANCE_STRATEGY: intergroup partition count balance
1 row in set (0.05 sec)

当前没有任务在跑，历史任务显示当时已经跑完了。

此外没有其他跟 BALANCE 有关的记录。

附加信息：这个租户属于 AP 业务，经常大批量数据写入。

#6

根据您提供的信息和查询结果，以下是对问题的分析与可能的原因：

1. 当前均衡任务的状态

  • 查询 CDB_OB_BALANCE_JOBS 表时发现一个均衡任务（JOB_ID: 4134532199）状态为 DOING，但其创建时间为 20 天前（2025-05-22），这表明该任务长时间未完成。
  • 然而，进一步查询 CDB_OB_BALANCE_TASKS 和 CDB_OB_BALANCE_TASK_HISTORY 表时发现：
    • 当前没有正在进行的任务（CDB_OB_BALANCE_TASKS 返回空集）。
    • 历史记录显示该任务下的子任务（TASK_ID: 4134532200）已经完成（STATUS: COMPLETED）。

这种现象可能表明：

  • 均衡任务的主作业状态未正确更新，导致其仍然显示为 DOING。
  • 或者，该任务在完成后未能正确清理或标记为完成。

2. 历史均衡任务的状态

  • 查询 CDB_OB_BALANCE_JOB_HISTORY 表时发现：
    • 最近的历史任务（JOB_ID: 4115707486）被取消，原因是分区模式发生变化（Canceled because partition schema changed during job）。
    • 更早的任务（JOB_ID: 4115703284）已完成，类型为 LS_BALANCE。

这表明租户的负载均衡任务可能受到以下因素的影响：

  • 分区模式频繁变化可能导致均衡任务中断。
  • 租户属于 AP 业务场景，经常有大批量数据写入，可能引发分区分裂或合并，从而影响均衡任务的稳定性。

3. 可能的原因分析

结合上述信息，以下是可能导致问题的原因：

  1. 任务状态未正确更新：
    • OceanBase 的均衡任务状态管理可能存在异常，导致任务状态未及时更新为 COMPLETED。
  2. 分区模式变化：
    • 租户属于 AP 场景，频繁的数据写入可能导致分区分裂或合并，进而触发均衡任务的重新调度或取消。
  3. 资源不足：
    • 如果集群资源紧张（如内存、CPU 或磁盘空间不足），可能会影响均衡任务的执行效率，导致任务长时间未完成。
  4. Bug 或异常：
    • 社区版可能存在某些已知或未知的 Bug，导致均衡任务状态异常。

4. 建议的解决步骤

为了进一步排查和解决问题，您可以按照以下步骤操作：

(1) 检查任务状态是否正确

  • 执行以下命令，手动检查任务状态是否可以更新为 COMPLETED：
    UPDATE oceanbase.CDB_OB_BALANCE_JOBS
SET STATUS = 'COMPLETED'
WHERE JOB_ID = 4134532199 AND TENANT_ID = 1042;
  • 注意：请确保任务确实已完成后再执行此操作，以免影响其他任务。

(2) 监控分区变化

  • 检查租户的分区模式是否频繁变化，可以通过以下查询获取分区信息：
    SELECT * FROM oceanbase.CDB_OB_PARTITIONS WHERE TENANT_ID = 1042;
  • 如果发现分区分裂或合并过于频繁，可以考虑调整分区策略以减少对均衡任务的影响。

(3) 检查资源使用情况

  • 检查 OBServer 的资源使用情况，确保没有资源瓶颈：
    free -m  # 查看内存使用情况
top      # 查看 CPU 使用情况
df -h    # 查看磁盘使用情况
  • 如果资源不足，可以考虑增加硬件资源或优化查询以减少资源消耗。

(4) 升级到最新版本

  • 如果问题持续存在，建议升级到最新的社区版（如 4.2.6 或更高版本），以修复可能存在的 Bug。

(5) 联系技术支持

  • 如果问题仍未解决，可以收集相关日志并联系 OceanBase 技术支持团队进行进一步分析。推荐使用 obdiag 工具采集日志：
    obdiag gather scene run --scene=observer.balance

5. 总结

当前均衡任务的状态异常可能是由于任务状态未正确更新、分区模式变化或资源不足等原因导致。建议按照上述步骤逐步排查，并根据实际情况采取相应的解决措施。如果问题仍无法解决，请提供更详细的日志信息以便进一步分析。

检索到的文档如下:

  1. Transfer Partition

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#7

近期处理过一个类似的bug。（现象 有个均衡的作业还在运行中（DOING )查询不到其他balance相关任务）原因是因为分区磁盘大小差异过大导致磁盘分区均衡无法完成，该问题在425bp4修复。

alloc failed reason is that single alloc size large than 4G is not allowed
日志问题查询历史工单也是由于负载均衡磁盘分区均衡异常导致，单分区过大（同表分区大小1.4T对比2GB）时可能遇到

可以提供一份observer日志，看看是否是同一个问题

#8

那很有可能。
日志我通过 消息发送 钉盘 链接给你了。
帮看看，谢谢。

#9

如果当前任务还存在处于doing状态，帮忙grep [BALANCE]相关日志看看
这个trace 麻烦老师也帮忙grep一下[YB420A0A0A24-000631AF9255F7C6-0-0]

#10

我发给你的 observer.log 里 grep 。

[admin@RS-OBDB-P1 log]$ grep "YB420A0A0A24-000631AF9255F7C6-0-0" observer.log|more
[2025-04-12 22:09:26.831448] WARN  [LIB] common_realloc (ob_tenant_ctx_allocator.cpp:544) [56524][T1042_TBalance][T1042][YB420A0A0A24-000631AF9255F7C6-0-0
] [lt=49][errcode=-4013] [OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)

[admin@RS-OBDB-P1 log]$ grep "\[BALANCE\]" observer.log|more

根据 BALANCE 搜索日志没有内容输出。

#11

知道是什么具体操作导致的吗？？看着像某些SQL执行失败抛出来的错误

#12

这点日志看不出来，试试grep observer.log*
如果还不行，把这个均衡任务停掉使用dmbs手动发起一次试试
DBMS_BALANCE.TRIGGER_PARTITION_BALANCE(balance_timeout INT DEFAULT NULL);
image

#13

如果再次触发，会提示已经有均衡任务。

MySQL [oceanbase]> CALL DBMS_BALANCE.TRIGGER_PARTITION_BALANCE(7200);
ERROR 4179 (HY000): balance job is in progress, trigger partition balance is not allowed

此时取消之前的均衡任务，会提示 “CANCELING"

MySQL [oceanbase]> ALTER SYSTEM CANCEL BALANCE JOB TENANT = 'ten011';
Query OK, 0 rows affected (0.02 sec)

select tenant_id, job_id, create_time, MODIFY_TIME ,BALANCE_STRATEGY ,JOB_TYPE ,TARGET_PRIMARY_ZONE_NUM ,TARGET_UNIT_NUM ,status,COMMENT  from oceanbase.CDB_OB_BALANCE_JOBS
where tenant_id=1042
order by create_time desc limit 10;

+-----------+------------+----------------------------+----------------------------+------------------------------------+-------------------+-------------------------+-----------------+-----------+-----------------------------+
| tenant_id | job_id     | create_time                | MODIFY_TIME                | BALANCE_STRATEGY                   | JOB_TYPE          | TARGET_PRIMARY_ZONE_NUM | TARGET_UNIT_NUM | status    | COMMENT                     |
+-----------+------------+----------------------------+----------------------------+------------------------------------+-------------------+-------------------------+-----------------+-----------+-----------------------------+
|      1042 | 4134532199 | 2025-05-22 12:17:20.555682 | 2025-06-14 09:17:57.439559 | intergroup partition count balance | PARTITION_BALANCE |                       3 |               1 | CANCELING | Manual operator balance job |
+-----------+------------+----------------------------+----------------------------+------------------------------------+-------------------+-------------------------+-----------------+-----------+-----------------------------+
1 row in set (0.01 sec)

已经无法再次对这个租户 的 primary_zone 做修改了。
三个 节点，只有 zone2 的节点会报上面这个错误。

alert.log 里尽是这种报错。

2025-06-14 05:57:23.819244|WARN|LIB|OB_LIB_ALLOCATE_MEMORY_FAIL|-4013|1042|13350|T1042_TBalance|YB420A0A0A25-000631AFB68B02B5-0-0|common_realloc|ob_tenant_ctx_allocator.cpp:544|"[OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)"
2025-06-14 06:50:31.383554|WARN|LIB|OB_LIB_ALLOCATE_MEMORY_FAIL|-4013|1042|13350|T1042_TBalance|YB420A0A0A25-000631AFB68B02B6-0-0|common_realloc|ob_tenant_ctx_allocator.cpp:544|"[OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)"
2025-06-14 07:43:55.892104|WARN|LIB|OB_LIB_ALLOCATE_MEMORY_FAIL|-4013|1042|13350|T1042_TBalance|YB420A0A0A25-000631AFB68B02B7-0-0|common_realloc|ob_tenant_ctx_allocator.cpp:544|"[OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)"
2025-06-14 08:36:50.579924|WARN|LIB|OB_LIB_ALLOCATE_MEMORY_FAIL|-4013|1042|13350|T1042_TBalance|YB420A0A0A25-000631AFB68B02B8-0-0|common_realloc|ob_tenant_ctx_allocator.cpp:544|"[OOPS]: alloc failed reason is that single alloc size large than 4G is not allowed(alloc_size: 8321499136)"

请问有没有你说的那个 BUG 的详细信息描述？

#14

这个报错太内核了

#15

最后 balance job 总算取消成功了， LS_ID 的数量也恢复正常。
告警也消失了。

已经找到 4.2.5.4 的修复缺陷简要说明： OceanBase 数据库CE版本发布说明 - OceanBase

image
image704×272 57.2 KB

6月6号发布的 BP4 ，还不敢用。

就先这样了。