observer4.3.3.1 CRASH ERROR

OceanBase 技术问题
#1

【 使用环境 】
生产环境
【 OB or 其他组件 】
OBServer
【 使用版本 】
ob4.3.3.1
【问题描述】清晰明确描述问题

  • OCP检测到OBServer crash告警，告警详情如下：
    告警详情：[OBServer crash] 集群：xxx，主机：xxx，日志类型：observer，日志文件：/home/admin/oceanbase/log/observer.log，日志级别：INFO，关键字=CRASH ERROR!!!，错误码=-1，日志详情=[2025-03-10 02:20:00.566981] INFO [DETECT] record_summary_info_and_logout_when_necessary_ (ob_lcl_batch_sender_thread.cpp:202) [1182150][T1013_LCLSender][T1013][Y0-0000000000000000-0-0] [lt=82] ObLCLBatchSenderThread periodic report summary info(duty_ratio_percentage=0, total_constructed_detector=0, total_destructed_detector=0, total_alived_detector=0, lcl_op_interval=30000, lcl_msg_map.count()=0, *this={this:0x7fbc014362b0, is_inited:true, is_running:true, total_record_time:5010000, over_night_times:0})CRASH ERROR!!! IP=7fbff026d46b, RBP=7fbf9a74fa80, sig=6, sig_code=-6, sig_addr=0x1f400004d3e, RLIMIT_CORE=unlimited, timestamp=1741544400567265, tid=20124, tname=MultiTenant, trace_id=Y0-0000000000000000-0-0, extra_info=(), lbt=0x1f666c38 0x1eef714d 0x7fbff04014bf 0x7fbff026d46b 0x7fbff026e790 0x1f1c1bc0 0x78910f8 0x789ad2b 0x788cfab 0x1f64fbc6 0x1f64f951 0x1f6524af 0x1f64b865 0xf0031e7 0xf00387f 0x7c793ee 0x7c77ed8 0x7c77bbd 0x1f652857 0x1f6509f6 0x7fbff03f6f1a 0x7fbff032c1bf, SQL_ID=, SQL_STRING=。
    【复现路径】问题出现前后相关操作
  • 查看主机监控，发现问题出现前后时间点，主机的系统负载比较高，但CPU使用率不高
    image
    image2546×1043 176 KB
  • 查看操作系统的系统日志未见异常
  • 集群已使用数据盘：28GB
  • 每日集群合并开始时间：2:00
  • 每日备份开始时间是：4:00
  • 目前Crash ERROR告警前后的OBServer日志已经被冲掉了
  • 通过addr2line工具，分析OBServer进程崩溃的代码位置
[root@observer1 opt]# addr2line -pCfe ./usr/lib/debug/home/admin/oceanbase/bin/observer.debug 0x1f666c38 0x1eef714d 0x7fbff04014bf 0x7fbff026d46b 0x7fbff026e790 0x1f1c1bc0 0x78910f8 0x789ad2b 0x788cfab 0x1f64fbc6 0x1f64f951 0x1f6524af 0x1f64b865 0xf0031e7 0xf00387f 0x7c793ee 0x7c77ed8 0x7c77bbd 0x1f652857 0x1f6509f6 0x7fbff03f6f1a 0x7fbff032c1bf

safe_backtrace at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/signal/ob_libunwind.c:30
oceanbase::common::coredump_cb(int, int, void*, void*) at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/signal/ob_signal_handlers.cpp:210
?? ??:0
?? ??:0
?? ??:0
ob_abort() at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/ob_abort.cpp:21
?? ??:0
oceanbase::lib::SubObjectMgr::alloc_object(unsigned long, oceanbase::lib::ObMemAttr const&) at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/alloc/object_mgr.h:50
oceanbase::lib::ObTenantCtxAllocator::alloc(long, oceanbase::lib::ObMemAttr const&) at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/alloc/ob_tenant_ctx_allocator.cpp:38
oceanbase::common::ob_malloc(long, oceanbase::lib::ObMemAttr const&) at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/allocator/ob_malloc.h:37
oceanbase::lib::ProtectedStackAllocator::_alloc(unsigned long, unsigned long, long, bool) at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/thread/protected_stack_allocator.cpp:83 (discriminator 2)
oceanbase::lib::ProtectedStackAllocator::alloc(unsigned long, long) at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/thread/protected_stack_allocator.cpp:62
oceanbase::lib::Threads::start() at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/thread/threads.cpp:181
oceanbase::omt::create_worker(oceanbase::omt::ObThWorker*&, oceanbase::omt::ObTenant*, unsigned long, int, bool, oceanbase::omt::ObResourceGroup*) at ./build_rpm/src/observer/./src/observer/omt/ob_th_worker.cpp:71
oceanbase::omt::ObResourceGroup::acquire_more_worker(long, long&, bool) at ./build_rpm/src/observer/./src/observer/omt/ob_tenant.cpp:425
oceanbase::omt::ObResourceGroup::check_worker_count() at ./build_rpm/src/observer/./src/observer/omt/ob_tenant.cpp:508
oceanbase::omt::ObTenant::check_group_worker_count() at ./build_rpm/src/observer/./src/observer/omt/ob_tenant.cpp:1786
oceanbase::omt::ObMultiTenant::run1() at ./build_rpm/src/observer/./src/observer/omt/ob_multi_tenant.cpp:2523
oceanbase::lib::Threads::run(long) at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/thread/threads.cpp:203
oceanbase::lib::Thread::run() at ./build_rpm/deps/oblib/src/lib/./deps/oblib/src/lib/thread/thread.cpp:177
?? ??:0
?? ??:0

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

2 个赞
#3

日志采集场景: observer无故重启
日志采集命令: obdiag gather scene run --scene=observer.restart

推荐使用 obdiag 工具进行日志采集，并且将采集到的日志提供给我们以便确认问题所在。此命令会收集与 observer 无故重启相关的日志信息，有助于分析导致 CRASH ERROR 的原因。

另外，为了确定具体的问题，在此需要您提供一些信息：

  1. 是否有特定的操作或时间段触发了该问题？例如，是否在执行某些 SQL 或者在高负载情况下出现？
  2. 出现 CRASH ERROR 前后，系统资源（如 CPU、内存、磁盘 I/O）的使用情况如何？是否有异常波动？
  3. 日志中除了 ‘CRASH ERROR!!!’ 关键字外，是否还有其他相关的关键错误信息或堆栈信息？
  4. 当前集群的部署模式是什么？是通过 OCP、OBD 部署还是手动部署的？
  5. 是否可以复现该问题？如果可以，请描述复现步骤。

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

1 个赞
#4

你好集群架构和主机的cpu类型是什么
执行下lscpu看看

1 个赞
#5

集群架构是：2-2-2
主机的CPU类型：

image
image2855×882 419 KB

1 个赞
#6

根据您提供的信息，我们可以从以下几个方面分析和排查问题：

1. 集群架构与硬件配置

  • 您的集群架构为 2-2-2（即两台机器，每台机器两个 Zone，每个 Zone 两个副本），这是一个典型的高可用架构。
  • 主机 CPU 类型为 Hygon C86 7288 32-core Processor，支持 AMD-V 虚拟化技术。主机运行在 KVM 虚拟化环境中，具有 64 个逻辑核（单 Socket，64 核心）。

2. 问题分析

(1) 日志中的关键信息

  • 日志中显示了 CRASH ERROR!!! 的关键字，并且提供了崩溃时的堆栈信息。通过 addr2line 工具分析，崩溃发生在以下代码路径：
    oceanbase::omt::ObMultiTenant::run1() at ./build_rpm/src/observer/./src/observer/omt/ob_multi_tenant.cpp:2523
    这表明问题可能与多租户管理模块有关，尤其是在创建或销毁线程时出现了内存分配失败的情况。

(2) 系统负载与资源使用

  • 根据您提供的监控数据，系统负载较高（load1 达到 1973.82），但 CPU 使用率并不高。这可能意味着系统存在 I/O 瓶颈或其他资源争用问题。
  • 内存分配失败可能是导致崩溃的原因之一。从堆栈信息来看，崩溃发生在内存分配函数 oceanbase::lib::ProtectedStackAllocator::_alloc 中，这进一步验证了内存不足的可能性。

(3) 每日合并与备份的影响

  • 每日合并开始时间为 2:00，备份开始时间为 4:00。崩溃时间点为 2:20，正好处于每日合并期间。合并操作会占用大量系统资源（如磁盘 I/O 和内存），可能导致系统资源不足。

3. 解决方案与建议

(1) 检查系统资源

  • 内存检查：确认主机是否有足够的内存供 OceanBase 使用。可以通过以下命令查看内存使用情况：
    free -m
  • 磁盘 I/O 检查：使用 iostat 或 dstat 工具监控磁盘 I/O 性能，确保没有 I/O 阻塞问题。
    iostat -x 1 10

(2) 调整合并与备份策略

  • 如果每日合并和备份对系统资源消耗较大，可以考虑调整合并和备份的时间窗口，避免高峰期重叠。
  • 可以通过 OCP 或手动调整合并参数，降低合并对系统的影响。例如，调整 major_freeze_duty_time 参数，限制合并的触发时间。

(3) 收集更多诊断信息

  • 使用 obdiag 工具收集更详细的日志信息，以便进一步分析问题原因：
    obdiag gather scene run --scene=observer.restart
  • 收集的日志包括核心转储文件、系统日志、OceanBase 日志等，有助于定位具体问题。

(4) 升级版本

  • 当前使用的版本为 4.3.3.1，建议关注官方发布的更新版本，可能存在针对类似问题的修复。

4. 总结

根据现有信息，问题可能与系统资源不足（尤其是内存）以及每日合并操作的高资源消耗有关。建议按照上述步骤逐步排查，并收集更多诊断信息以便进一步分析。如果问题仍然无法解决，可以联系 OceanBase 技术支持团队获取帮助。

检索到的文档如下:

  1. 展示 Session 详细状态
  2. 删除分区

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

1 个赞
#7

这个问题比较内核了

#8

麻烦看一下，崩溃后log路径是否存在core文件

#9

有core文件，大小看了下48个GB，压缩后6.3GB，如何传给你呢

#10

这是我本地，gdb分析的，好像没看到关键信息
gdb ./usr/lib/debug/home/admin/oceanbase/bin/observer.debug core-MultiTenant-19774-1741544400 -ex bt

…省略了非关键输出…
[New LWP 258846]
[New LWP 19888]

warning: .dynamic section for “/lib64/librt.so.1” is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for “/lib64/libdl.so.2” is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for “/lib64/libm.so.6” is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for “/lib64/libaio.so.1” is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for “/lib64/libpthread.so.0” is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for “/lib64/libc.so.6” is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for “/lib64/ld-linux-x86-64.so.2” is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for “/lib64/libnss_files.so.2” is not at the expected address (wrong library or version mismatch?)

warning: File “/usr/lib64/libthread_db-1.0.so” auto-loading has been declined by your `auto-load safe-path’ set to “$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py”.
To enable execution of this file add
add-auto-load-safe-path /usr/lib64/libthread_db-1.0.so
line to your configuration file “/root/.gdbinit”.
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file “/root/.gdbinit”.
For more information about this security protection see the
“Auto-loading safe path” section in the GDB manual. E.g., run from the shell:
info “(gdb)Auto-loading safe path”

warning: Unable to find libthread_db matching inferior’s thread library, thread debugging will not be available.

warning: File “/usr/lib64/libthread_db-1.0.so” auto-loading has been declined by your `auto-load safe-path’ set to “$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py”.

warning: Unable to find libthread_db matching inferior’s thread library, thread debugging will not be available.
Core was generated by `/home/admin/oceanbase/bin/observer’.
Program terminated with signal 6, Aborted.
#0 0x00007fbff040135b in ?? ()
#0 0x00007fbff040135b in ?? ()
#1 0xeddfff8000005200 in ?? ()
#2 0x0000000000000000 in ?? ()
(gdb)
(gdb)
(gdb) quit

#11

麻烦确认下是合并结束后才core的么

#12

学习打卡 :clap: :clap: :clap:

#13

你好，麻烦私信留下你的丁丁号这边加一下你。这边需要收集一下croe文件和/usr/lib64下的所有so文件

#14

当天的合并情况

a40970b8c35a5db1d7ed2fffcd1ce05
a40970b8c35a5db1d7ed2fffcd1ce05746×292 7 KB

#15

继续学习