---
title: 如何诊断 OBServer 异常退出问题-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于如何诊断 OBServer 异常退出问题相关的常见问题和使用技巧，帮助您快速解决如何诊断 OBServer 异常退出问题的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# 如何诊断 OBServer 异常退出问题

更新时间：2026-06-04 01:56

适用版本： V1.4.x、V2.1.x、V2.2.x、V3.1.x、V3.2.x 内容类型：How-to  

正在运行中的 OBServer 异常退出，通过操作系统（如 `ps -ef` 命令）查询 observer 进程不存在。 OBServer 在退出时生成了 core dump 文件。通常生成的 core dump 文件比较大，大致是几十或者上百 GB。 需要进行应急操作以及 OBServer 的异常退出进行根因分析。

通常情况下，OBServer 可能由于无效内存访问，进程放弃等异常原因退出。一般情况下是由于 OBServer 本身的问题，或者由于操作系统或者底层的原因导致的，具体问题需要进行分析。通常情况下，如果不是硬件损坏或者操作系统的问题，需要重新拉起 observer 作为应急操作。

在 OBServer V1.x 以及 V2.2.30 BP16 之前的版本，需要直接调试 core dump 文件进行根因分析。在 OBServer V2.2.30 BP16 及以上，OBServer V2.2.7x ，OBServer 3.x 及以上的版本进行了诊断功能的增强。对于异常退出的场景，会直接在 `observer.log` 中打印携带 `CRASH ERROR!!!` 关键字的 call stack（也称 backtrace）的信息，这里包含了 OBServer 异常退出的直接原因和问题现场。

```shell
CRASH ERROR!!! sig=11, sig_code=1, sig_addr=0x42, tid=27311, tname=test_context, trace_id=Y0-0000000000000000, extra_info=((null)), lbt=0x58b9f0 0x58c00f 0x7fcb153fe61f 0x4a1342 0x9fc8fb 0x9f66f5 0x9dc80e 0x9dd097 0x9dd727 0x9e3fdf 0x9fdcd9 0x9f74eb 0x9e2c1b 0x4abcc0 0x4a801b 0x7fcb144b6444 0x4a1028 Segmentation fault (core dumped)

```

在分析 OBServer 异常退出产生 core dump 问题的过程中，首要的任务就是要判断是否是遇到了已知的问题。特别是当 core 文件比较大，不便传回给 OceanBase 技术支持，或者是在生产环境无法直接将文件发回给 OceanBase 技术支持时，可以先在问题现场对异常退出时的 observer 的退出信息进行初步诊断。对于诊断 OBServer 异常退出问题，最重要的是获取 OBServer 异常退出时的直接原因以及退出线程的线程栈信息。

在 OBServer V2.2.76 版本以前，需要经 OceanBase 技术支持团队获取 OBServer 的 debuginfo rpm 包，在安装或者解压后才可以有能力将 OBServer 线程的 call stack 信息翻译成可读的方法名，或者调试 core 文件。在 OBServer V2.2.76 版本之后，可以直接通过 OBServer 的可执行文件获取线程栈的 call stack 信息，或者调试 core 文件。但是需要获得更全的调试信息，仍需要直接安装 debuginfo 的包。请注意在 V2.2.76 高版本需要 gdb 9.1 以上的版本才能有效加载 debuginfo 信息。

- V2.2.76 版本以前

     1. 将 observer debuginfo 的 rpm 包进行解压，需注意，需要解压与 observer 版本一一对应的版本。

       ```shell
       rpm2cpio oceanbase-debuginfo-xxx.el7.x86_64.rpm | cpio -div

       ```
     2. 将解压出的 `observer.debug` 文件拷贝进 observer 目录，默认为 `/home/admin/oceanbase/bin` 目录。
 - V2.2.76 及以上版本

     - 如果 `observer.log` 里在进程退出时生成了 `CRASH ERROR!!!` 关键字，记录了 OBServer 线程异常退出的 call stack 重要信息 （'lbt=' 关键字后尾随的地址hex值），执行一下命令获取线程信息：

      ```shell
      addr2line -pCfe $observer $symbol_addr

      ```

      在获取到以上信息后请将 `CRASH ERROR!!!` 原始信息和打印的线程栈信息发送给技术支持人员协助处理。
     - 如果还处在低版本，不具备上述信息，需要直接 debug core 文件时，可以执行以下命令。不过请注意本文是在调试 core 文件。如果是直接调试运行中的 observer，会直接影响系统的可用性。请在执行下列命令时，按照给出的命令执行。

      ```shell
      gdb $observer $core_file

      ```

      示例：

      ```shell
      gdb /home/admin/oceanbase/bin/observer core-observer-113058-1614065734

      ```

      在进入交互界面之后

      ```shell
      set logging file /home/admin/oceanbase/gdb-output
      set logging on
      set pagination off
      set print pretty on
      set print elements 0
      bt
      bt full
      info r
      info thread
      set logging off
      quit

      ```

      在执行 gdb 获取到关键信息后可在交互页面输入 quit 命令退出 gdb, 所有的 debug 信息会输出在 gdb-output 文件里。

      输出结果 backtrace (bt) 的关键信息如下：

      ![1](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/cluster-management/2000.observer/5200.how-to-diagnose-observer-abnormal-exit-issues/1.png)

      在信息收集成功后请将包含进程退出的直接原因（signal 信息）和线程栈信息发送给 OceanBase 技术支持。

## 适用版本

OceanBase 数据库 V1.x、V2.x、V3.x 版本。

上一篇

[OceanBase 出现 unexpected store ctx total access count 告警的原因](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002393954)

下一篇

[OBServer 无法启动，出现 Structure needs cleaning 报错](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003340854) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线