---
title: 并发修改配置项可能导致 RS 所在的 OBServer 节点大量线程卡住和租户队列积压-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于并发修改配置项可能导致 RS 所在的 OBServer 节点大量线程卡住和租户队列积压相关的常见问题和使用技巧，帮助您快速解决并发修改配置项可能导致 RS 所在的 OBServer 节点大量线程卡住和租户队列积压的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

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

划线反馈

# 并发修改配置项可能导致 RS 所在的 OBServer 节点大量线程卡住和租户队列积压

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

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

## 问题现象

在 OceanBase 集群扩容过程中，在 add server 之后，云平台会并发调用 `setObServerMemoryParameter`，修改所有新 add server 的 memory 配置项，这时会触发该问题，QPS 降至 0 和 RT 显著上升、RS 节点上租户队列积压和打爆和大量线程 hung 住等异常现象。 另外在 QA 环境复现，add server 不是触发本问题的必要条件，只要并发修改配置项或者连续不间断地批量修改配置项也可能触发这个问题。

## 关键诊断信息

### 触发条件

- 在扩容过程中通过云平台批量添加多个 OBServer，云平台并发调用 `setObServerMemoryParameter`（云平台最新版本已规避，改成了串行调用 `setObServerMemoryParameter` 修改配置项）。
 - 并发修改集群配置项或租户配置项，修改配置项的并发越大就越容易触发。
 - 单并发情况下，连续不间断地修改配置项，也有小概率触发这个问题。

### 事前巡检

- 无。

### 事后诊断

- 查询 `dba_ob_server_event_history`，查看是否有相同时间点批量执行 `ALTER SYSTEM SET` 修改配置项的情况。

  ```shell
  SELECT * FROM dba_ob_server_event_history WHERE timestamp > '2025-09-01 12:41:50'
  AND timestamp < '2025-09-01 12:45:00' AND module = 'sql' ORDER BY timestamp DESC LIMIT 100;

  ```

  如下图所示，如果有大量 `ALTER SYSTEM` 修改配置项的事件，而且执行的时间点十分接近，则很容易触发这个问题：

  ![image01](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/cluster-management/2000.observer/11648.concurrent-modification-configuration-items-may-cause-large-number-threads-ob-node-rs-located-stuck-tenant-queues-backlogged/20250930concurrent-modification-configuration-items-may-cause-large-number-threads-ob-node-rs-located-stuck-tenant-queues-backlogged01.png)
 - 保留流量跌0时的 obstack 堆栈，大量线程卡在 `ObTenantConfigMgr::get_tenant_config_with_lock` 等锁上，如下图所示：

  ![image02](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/cluster-management/2000.observer/11648.concurrent-modification-configuration-items-may-cause-large-number-threads-ob-node-rs-located-stuck-tenant-queues-backlogged/20250930concurrent-modification-configuration-items-may-cause-large-number-threads-ob-node-rs-located-stuck-tenant-queues-backlogged02.png)
 - 查看 RS 节点的 observer.log 日志，过滤 `[ConfigMgr]` 线程的日志，可以看到持续出现 -6004 重试的报错，过滤命令如下：

  ```shell
  grep -rnI "\[ConfigMgr\]" observer.log.xxx

  ```

  ![image03](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/cluster-management/2000.observer/11648.concurrent-modification-configuration-items-may-cause-large-number-threads-ob-node-rs-located-stuck-tenant-queues-backlogged/20250930concurrent-modification-configuration-items-may-cause-large-number-threads-ob-node-rs-located-stuck-tenant-queues-backlogged03.png)

## 问题原因

OBServer 中，并发修改或者不间断地批量修改多个配置项，可能会导致死锁问题，死锁过程中会占住一把全局的写锁，导致大量线程都被 hung 住，从而触发队列积压和流量跌 0 等异常。

具体解释一下配置项更新死锁的 BUG： 当用户执行sql修改配置项之后，RS节点会执行下面两步骤。

1. 修改 `__all_sys_parameter`（修改集群配置项的时候）或者 `__tenant_parameter` 内部表（修改租户配置项的时候），然后事务提交、写日志，完成之后会调度一个本地更新配置项文件的任务，交给 `ConfigMgr` 线程处理。
 2. `ConfigMgr` 线程处理任务，先加全局的 `ObTenantConfigMgr` 写锁，再查询 `__all_sys_parameter` 或者 `__tenant_parameter` 内部表，从内部表里读到结果后，把配置项转储到 `etc/observer.config.bin` 文件中。

在写日志的时候，日志回调线程 `LogIOCb` 需要获取 `data_version` 的租户配置项，需要加 `ObTenantConfigMgr` 的读锁，而在日志没有提交的时候，`ConfigMgr` 执行 `inner sql` 的时会返回 -6004 锁冲突，然后重试知道超时，所以这时候 `ConfigMgr` 和 `LogIOCb` 线程就构成了一个死锁，`ConfigMgr` 等待 `LogIOCb` 写完日志，而 `LogIOCb` 等待 `ConfigMgr` 释放 `ObTenantConfigMgr` 的锁。在并发修改配置项或者连续批量修改配置项的时候，就容易触发这个问题。

因为 `ConfigMgr` 查询内部表的超时默认是 30s，所以在达到超时之后，会释放 `ObTenantConfigMgr` 写锁，如果写日志的 `LogIOCb0` 线程这时候加锁成功并写完了日志，死锁就会恢复。但如果日志没有完成，`ConfigMgr` 线程会继续重试，继续加 `ObTenantConfigMgr` 写锁，死锁持续，需要等待下一次 30s 超时。

## 问题的风险及影响

**稳定性风险：** RS 所在的 OBServer 大量线程 hung 住，租户队列积压，业务流量降至 0。

## 影响租户

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

## 影响版本

OceanBase 数据库企业版 V4.2.5 GA（oceanbase-4.2.5.0-100000082024102022）及之后版本。

## 解决方法

- 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.5 BP6 Hotfix1（oceanbase-4.2.5.6-106010022025092415）版本、V4.2.5 BP6 Hotfix2（oceanbase-4.2.5.6-106020012025102316）版本、V4.2.5 BP6 Hotfix3（oceanbase-4.2.5.6-106030012025112319）版本、V4.2.5 BP7（oceanbase-4.2.5.7-107000092025103121）及之后版本。
 - 停止修改配置项，通常情况下，死锁会在多次超时后自动恢复，但恢复时间不确定。
 - 若长时间未能恢复，可考虑切换 RS 主节点或重启 RS 节点。

## 规避方式

- 避免并发修改配置项、连续不间断地修改多个配置项。
 - 云平台新版本将调整 `setObServerMemoryParameter` 步骤改为了串行执行，避免在批量 add server 的时候触发这该问题。

上一篇

[1F-1F-1F 三节点分布在三个地域的 OceanBase 集群创建多副本业务租户时失败的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003907877)

下一篇

[关于 OBServer 进程 crash 时产生的 coredump 文件大小及压缩说明](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000004409698) ![有帮助](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) 咨询热线