---
title: 队列爆自动 obstack 功能可能导致 OBServer 暂时 hang 住-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于队列爆自动 obstack 功能可能导致 OBServer 暂时 hang 住相关的常见问题和使用技巧，帮助您快速解决队列爆自动 obstack 功能可能导致 OBServer 暂时 hang 住的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

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

划线反馈

# 队列爆自动 obstack 功能可能导致 OBServer 暂时 hang 住

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

适用版本： V4.2.x 内容类型：Troubleshoot  

## 问题现象

1. OBServer 进程短时间 hang 死，现象类似 `gcore`/`gdb attach`，之后自行恢复。
 2. 前置问题为队列爆，hang 的时间长度与进程内存大小相关，目前不清楚是否为线性关系，观察到 600G 的进程大约卡住 10s。
 3. 该问题仅存在 OceanBase 数据库 V4.2 及之后所有版本，此前版本不存在此问题。

## 关键诊断信息

### 触发条件

租户队列爆。

### 事后诊断

1. OBServer 进程 hang 期间 observer.log 日志中断，CPU 和网卡带宽会跌至很低，如执行 `tsar --cpu` 命令。

   ![image](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/cluster-management/20250307auto-obstack-function-may-cause-ob-hang01.png)
 2. 恢复后会有其他模块响应日志超时，打印日志信息。

   ```shell
   [2024-01-31 19:29:22.732486] EDIAG [RPC.FRAME] batch_rpc_easy_timer_cb (ob_net_easy.cpp:641) [4940][BatchIO][T0][Y0-0000000000000000-0-0] [lt=9][errcode=0] LOGGER COST TOO MUCH TIME, cost: 9062019, time dist: FORMAT_END=9041611, ALLOC_END=20407, APPEND_END=0, BACKTRACE: 0x7861450 0x79187df 0x7a763e9 0x7a761c4 0x7947071 0x78da6cb 0x17ac5e2d 0x78611e5 0x1982ba15 0x78f31b9 0x198390dc 0x172524aa 0x1724e895 0x7fa0a4e08e25 0x7fa0a4b32bad

   ```

   功能触发时也会有 faststack 日志，但是只有触发时 ret=0，如下图所示。

   ![image02](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/cluster-management/20250307auto-obstack-function-may-cause-ob-hang02.png)
 3. 不管是否有无 obstack 结果文件产生，都存在这个问题。

## 问题原因

租户队列爆场景保留 obstack 是 OceanBase 数据库 V4.x 版本新增的诊断功能（用于内核自动保留队列爆时的堆栈辅助研发诊断），该功能依赖 obstack。该功能默认开启，但有半小时的最小触发间隔（也可以通过这个工具调整），因此不会过于频繁的 hang 住，也可以基于这个特性来判断是否确实是该问题，即如果队列长时间爆，是否有固定半小时一次的进程卡住；问题的根因是由于该功能依赖于 obstack，因此实现上需要通过创建子进程来调用 obstack 抓去 OBServer 堆栈。Linux 下的 clone 调用会导致父进程 hang 住直到成功，clone 实际耗时与进程内存大小相关（观察到），因此在大内存场景（几百 GB）会较为明显。

## 问题的风险及影响

可能导致该 server 上的业务流量短时间跌 0，以及其他涉及该 server 的请求卡住。因此该问题的实质是故障的租户影响了租户所在 server 的所有租户的请求。

## 影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

## 影响版本

OceanBase 数据库企业版本 V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）之后版本。

## 解决方法

- 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.1 BP5（oceanbase-4.2.1.5-105000072024041817）、V4.2.3（oceanbase-4.2.3.0-100000052024041220）。
 - 无需特殊处理，会自行恢复，确定问题后规避即可，但该问题的前置问题租户队列爆一般需要重启恢复。强烈建议查清队列爆的原因。

## 规避方式

以下满足其一即可。

1. 避免租户队列爆。
 2. 通过其他方式降低进程内存水位以降低卡住时间，如 `memory_chunk_cache_size`。
 3. 彻底关闭自动保留堆栈功能（推荐），不需要重启。

   ```shell
   # OBServer 的安装目录
   cd /home/admin/oceanbase
   # 创建目录
   mkdir tools;
   # 不要 chmod +x，不能有 x 权限
   touch tools/callstack.sh

   ```

上一篇

[OBServer 重启后，建已存在表耗时 30s](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002397567)

下一篇

[生产环境升级 OBServer 版本至 V4.2.5 BP4 后查询并发首次执行报错 5136](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003228338) ![有帮助](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) 咨询热线