---
title: 大查询挂起线程数 lq_waiting_workers_.size() 异常-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于大查询挂起线程数 lq_waiting_workers_.size() 异常相关的常见问题和使用技巧，帮助您快速解决大查询挂起线程数 lq_waiting_workers_.size() 异常的难题。
---
切换语言

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

划线反馈

# 大查询挂起线程数 lq_waiting_workers_.size() 异常

更新时间：2026-05-28 02:06

适用版本： V2.2.x、V3.1.x、V3.2.x 内容类型：Troubleshoot  

## 问题现象

长期使用的 OceanBase 数据库 V2.2.3 版本的集群，有 10 台左右的机器监控指标cpu_usage 不准确，并触发了一系列运维问题。

以其中几台为例，单机的物理 CPU 使用率很低，只有 3-5C 左右。

![image01](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240904lqwork001.png)

但是监控项 cpu_usage 非常高，大概有 30C 左右。

![image02](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240904lqwork002.png)

经过排查发现对应租户的 dump tenant info 日志中，大查询挂起线程数 `lq_waiting_workers_.size()` 的数值异常，只有 -123，这个数值预期应该是 `>=0`（大于等于零）的。

![image03](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240904lqwork003.png)

而租户的调度巡检要保证租户的活跃线程数 `token_cnt` 恒定，因此会计算出需要分配的总线程数 `workers = token_cnt + lq_waiting_workers_.size()`，正常情况下 `lq_waiting_workers_.size() >=0`，所以总线程数 `workers` 一般会 `>= token_cnt`，但 `lq_waiting_workers_.size()` 数值异常为负，这就导致 `workers` 分配的明显偏少，预期要有至少 154 个，实际只有 31 个。

造成此次影响的是 `cpu_usage` 的不准。这是因为 `cpu_usage` 是通过 `token_cnt` 来计算的，因为异常导致的理论 `token_cnt` 比实际分配出来的线程数 `workers` 偏大，计算的 `cpu_usage` 也会比实际的使用率偏大。另外 `lq_waiting_workers_.size()` 异常还有可能导致租户线程数不够从而处理负载的能力不够，出现队列积压等现象。

## 关键诊断信息

### 触发条件

线程被判定为处理大查询请求而挂起后，达到 `wait_timeout` 触发自身唤醒。

出现概率一方面取决于场景大查询的数目，另一方面取决于大查询阈值 `large_query_threshold` 和 `wait_timeout` 数值，`large_query_threshold` 越小，`wait_timeout` 越小，这个问题概率就会更大，这两个值在各个版本默认值如下。

| 版本 | large_query_threshold | wait_timeout |
| --- | --- | --- |
| V2.2.6 及老版本 | 100ms | query_timeout |
| V2.2.77 及新版本 | 5s | 60s |

并且这个要累积到一定的次数后才能产生可感知的影响。前面所述长期使用的 OceanBase 数据库 V2.2.3 版本的集群，有 10 台左右的机器监控指标cpu_usage 不准确的场景，`lq_waiting_workers_.size()` 的数值可能在很早出现异常了，逐渐累积，造成租户工作线程数明显不足，`cpu usage` 统计不准确等。

### 事前巡检

将 `large_query_threshold` 设置的尽可能大，能减小问题发生概率。

### 事后诊断

查询 `dump_tenant_info`，其中的 `lq_waiting_workers_.size()` 字段为负数。

![image04](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240904lqwork004.png)

## 问题原因

老代码缺陷。大查询挂起线程的唤醒有一个并发问题，会导致 `lq_waiting_workers_.size()` 重复减。

具体的，挂起唤醒有两条路径，其一是常规路径，由其他线程执行一小段调度逻辑来唤醒。

![image05](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240904lqwork005.png)

另一条路径非常规，是被挂起的线程自身 `wait timeout` 后唤醒自己。

![image06](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240904lqwork006.png)

这里是先判定 `node->next` 是否为 null，后加锁。但有可能在加锁前 `node->next` 被置为 null，导致重复 remove。

观察队列本身的实现，在 unlink 前只对当前的 node 判空，没有对 `node->next` 判空

![image07](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240904lqwork007.png)

这会导致后面的 `size_--` 被重复执行。

因此在被挂起的线程 `wait timeout` 后可能会导致 `lq_waiting_workers.size()` 被重复减，累积一定次数之后可能就会变为负值。

## 问题的风险及影响

- 可能导致租户工作线程数不足，租户没有足够的处理负载的能力，导致队列积压等现象发生。
 - 可能导致租户 `cpu_usage` 计算不准确，数值持续性的明显偏大。

## 影响租户

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

## 影响版本

OceanBase 数据库企业版 V2.2.77 GA（oceanbase-2.2.77-20210508211731）及之后版本、V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.2 GA（oceanbase-3.2.2-20211130225726）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本。

## 解决方法及规避方式

- 解决方法：

     - 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP3（oceanbase-3.2.3.0-20220622171245）。
     - 如果因为线程数不够而明显的影响了租户负载能力造成队列积压，或者 `cpu_usage` 不准确影响了运维和监控，可以通过重启 OBServer 恢复。
 - 规避方式：

     - 尽量设置比较大的大查询阈值 `large_query_threshold`，可减小问题发生的概率。
     - 尽量不触发大查询请求。

上一篇

[高并发 select for update 场景 hang 死](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001394539)

下一篇

[OBServer 在执行 select for update 对主键加锁的场景下，可能会导致主表中数据的大小写发生变化](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000048155) ![有帮助](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) 咨询热线