---
title: 应用接收 RPC 会话未找到错误分析与解决方法-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 应用接收 RPC 会话未找到错误分析与解决方法相关的常见问题和使用技巧，帮助您快速解决 应用接收 RPC 会话未找到错误分析与解决方法的难题。
---
切换语言

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

划线反馈

# 应用接收 RPC 会话未找到错误分析与解决方法

更新时间：2025-12-05 04:36

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

## 问题现象

在 OceanBase 数据库中，如果租户 CPU 规格比较大，触发了远程执行的 SQL 并发过大可能会遇到 `rpc session not found` 报错。

## 关键诊断信息

### 触发条件

- 在业务 SQL 执行过程中触发远程查询、远程 LOB 列的查询、远程执行 INNER SQL，并发量较大时，可能导致远程节点处理的线程数达到 100 的硬限制，从而导致报错。
 - 集群规模较大、租户 CPU 规格较高的环境，并且如果遇到 CPU 瓶颈或者网络 IO 瓶颈的情况下，会更容易触发这个问题。

### 事前巡检

无。

### 事后诊断

- SQL 执行报错 `-4067 RPC session not found` 错误，或者报错 -4012 报错提示是 `RPC session not found`。
 - 搜索报错事件段内的 observer.log，看是否存在 `current wait thread >= max wait` 的 WARN 日志，如果有，则说明触发了该问题。

  ```shell
  grep -rnI max_waiting_thread_count observer.log.202508250*

  ```

  输出结果如下：

  ![image](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/connection/20251009analysis-and-solution-for-error-application-receives-rpc-session-not-found.png)

  如果日志没有匹配，则可能[处理流式 RPC 结果超过 30s 的限制 导致 RPC session not found 报错](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000865576?back=kb)中的问题。

## 问题原因

在 OBServer 流式 RPC 的实现里，目的端 OBServer 收到一个流式 RPC，如果需要多次回包，在每次回包之后会陷入阻塞，等待源端 OBServer 收到并处理完回包后发送下一个请求过来。为了避免大部分租户工作线程都被 hang 住，OBServer 的代码里对目的端 OBServer 陷入阻塞的线程数限制最大不能超过 100 的硬限制，在超过 100 之后，流式 RPC 的处理端提前结束，导致用户 SQL 抛出 -4067 错误。 如果环境中集群规模和租户 CPU 规格都比较大，在用户 SQL 触发远程执行、远程 LOB 查询、远程执行 INNER SQL，执行的结果集比较大就会触发这类流式 RPC 的 SQL 请求的并发量比较高的时候，很容易遇到突破上面这个的 100 的限制，导致用户 SQL 大量报错。

## 问题的风险及影响

SQL 执行报错。

## 影响租户

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

## 影响版本

OceanBase 数据库企业版 V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本、V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）及之后版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本、V4.2.5 GA（oceanbase-4.2.5.0-100000082024102022）及之后版本、V4.3.0（oceanbase-4.3.0.0-100000072024020200）及之后版本、V4.3.5 GA（oceanbase-4.3.5.0-100000122024123020）及之后版本。

## 解决方法

- 应急方法：降低用户 SQL 并发量。
 - 彻底解决：升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.1 BP11 Hotfix7（oceanbase-4.2.1.11-111070032025081120）版本、V4.2.1 BP11 Hotfix8（oceanbase-4.2.1.11-111080012025082014）版本、V4.2.1 BP11 Hotfix9（oceanbase-4.2.1.11-111090012025091215）版本、V4.2.1 BP11 Hotfix10（oceanbase-4.2.1.11-111100012025092309）版本、V4.2.1 BP11 Hotfix11（oceanbase-4.2.1.11-111110012025101314）版本、V4.2.1 BP11 Hotfix12（oceanbase-4.2.1.11-111120022025110311）版本、V4.2.5 BP6（oceanbase-4.2.5.6-106000052025082216）及之后版本、V4.3.5 BP4（oceanbase-4.3.5.4-104000052025090918）及之后版本，并调整隐藏配置项 `_stream_rpc_max_wait_thread_count`。

  #### 警告

  调整隐藏配置项 `_stream_rpc_max_wait_thread_count` 有一定的风险，请勿在生产库上自行调整，请联系咨询 OceanBase 技术支持团队获得帮助。

## 规避方式

- 降低用户 SQL 并发量。
 - 如果是 V4.2.1，V4.2.x，V4.3.x 版本，升级至修复版本后，根据租户的 CPU 规格，调整隐藏配置项 `_stream_rpc_max_wait_thread_count` 的值，建议值为：租户 `min_cpu * cpu_quota_concurrency * 0.5`。

  #### 注意

  如果在 V4.2.1 版本修改了该配置项，则只支持升级到 V4.2.5 BP6 以及之后的版本，否则在升级之后该配置项会失效。
 - V4.4.1 及其后续版本，将这个限制改成了租户级的限制，限制值为 `max(100, max_cpu * cpu_quota_concurrency)`，通常能够避免超过限制的情况，如果还是遇到超过限制的情况，可以调整节点上租户的 `max_cpu` 规避。

上一篇

[普通用户连接时遇到报错 ERROR 1040 (08004): Too many connections](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002356015)

下一篇

[OceanBase 数据库网络速率配置方案](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000813955) ![有帮助](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) 咨询热线
