---
title: 排查 schema 或 session 泄露问题-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 排查 schema 或 session 泄露问题相关的常见问题和使用技巧，帮助您快速解决 排查 schema 或 session 泄露问题的难题。
---
切换语言

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

划线反馈

# 排查 schema 或 session 泄露问题

更新时间：2025-06-17 09:06

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

本文介绍如何排查 schema 或 session 泄露问题。

OceanBase 数据库中 schema 槽位泄漏导致的内存不断上涨。即使槽位的泄露也会导致内存不断上涨，原因如下：

- 引用是 get_tenant_schema_schema_guard 瞬间产生，reset 或者析构时释放。
 - 占用所有槽位会导致内存增长速度变快。
 - 占用部分槽位时只要有一个引用计数没释放，schema 就无法 switch_allocator 释放内存，后续随着 DDL 的执行，新增的 schema 版本会放在同一个 allocator 上，泄漏速度比占满所有槽位略慢。

## 排查 schema 或 session 泄露的思路

- 确认 schema 是否有泄漏。

  通过 `SCHEMA_STATISTICS` 关键词过滤 observer 日志文件找到 `ref_cnt` 不为 0 的最小 schema 版本号 schema_version 值。

  ```shell
  grep 'SCHEMA_STATISTICS' observer.log

  ```

  输出结果如下：

  ```shell
  observer.log.20220606105744:[2022-06-06 10:57:41.996468] INFO  [SHARE.SCHEMA] ob_schema_mgr_cache.cpp:549 [366548][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=126] [SCHEMA_STATISTICS]dump schema_mgr_item(
    i=17, ret=0, tenant_id=1002, schema_version=1654219558961856,
    schema_count=5346, schema_size=15782482, ref_cnt=1,
    mod_ref_cnt=[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0])
  observer.log.20220606105744:[2022-06-06 10:57:42.003731] INFO  [SHARE.SCHEMA] ob_schema_mgr_cache.cpp:549 [366548][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=162] [SCHEMA_STATISTICS] dump schema_mgr_item(
    i=22, ret=0, tenant_id=1002, schema_version=1654345586613792,
    schema_count=4469, schema_size=13714700, ref_cnt=1,
    mod_ref_cnt=[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0])

  ```

  示例日志指出，1002 租户仍引用两个旧的 schema 版本（6 月 3 日和 6 月 4 日的），可能存在泄露。

  schema_version=1654219558961856 = 6月3日09:25 schema_version=1654345586613792 = 6月4日20:26
 - 确认是否有 session 泄漏。

  通过 `get current session count` 关键词过滤 observer 日志文件获取当前会话数。检查分配出去的 session 数（used_session_count）和 session mgr 中记录的 session 数（hold_session_count）是否相等。如果这两个计数不一致，可能存在 session 泄漏。

  ```shell
  grep 'get current session count' observer.log.2022060611*

  ```

  输出结果如下：

  ```shell
  observer.log.20220606110048:[2022-06-06 11:00:43.344867] INFO  [SQL] ob_sql_session_mgr.cpp:487 [366332][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=6] get current session count(
    used_session_count=1825, hold_session_count=1825, session_leak_count_threshold=100)
  observer.log.20220606110203:[2022-06-06 11:01:58.651943] INFO  [SQL] ob_sql_session_mgr.cpp:487 [366332][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=6] get current session count(
    used_session_count=1928, hold_session_count=1928, session_leak_count_threshold=100)

  ```

  示例日志显示，两个计数相等，意味着分配的 session 均被正常管理，说明不存在泄露，若想整体了解 session 信息可查看视图 `__all_virtual_session_info`。

  #### 注意

  并发场景下，存在两个数不一致的情况，并发后会保持一致。
 - 确认是否有长 Query。

  查看数据库的内部表 `__all_virtual_session_info`，发现长时间运行的 SQL（即使已经尝试 kill 掉，但没有退出）所处的 session 信息。

  ![uioy8-uiy789-huy9678-79jut89](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240202shemaandsession.png)

  进一步确认 session 具体情况可通过 `pstack` 线程号在堆栈中确定进程卡在哪里，另外也可采用 `top -H` 来查看线程的 CPU 使用情况，判断是否陷入死循环。

## 内部表 __all_virtual_session_info 和__all_virtual_processlist 的区别

- 用途不同。

     - 内部表 `__all_virtual_session_info` 是面向内核的，包含 session mgr 中所有 session 状态 ACTIVE、SLEEP、KILLED、REMOTE SESSION 等。
     - 内部表 `__all_virtual_processlist` 是用户层面，仅展示与用户连接相关的session 信息。该视图主要用于了解当前连接到数据库的用户进程信息。
 - 内容不一样。

     - 内部表 `__all_virtual_session_info` 包含 `ref_count`、`backtrace`、`thread_id` 等诊断内容，常用于查 bug。
     - 内部表 `__all_virtual_processlist` 只是展示会话信息。

两个内部表的主要区别在于它们的使用目的和提供的信息范围，前者用于内核诊断，后者用于用户级的进程信息展示。

## 适用版本

OceanBase 数据库所有版本。

上一篇

[GV$SYSSTAT 中租户 cpu_usage 的统计方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000297648)

下一篇

[IO hang 导致磁盘 invalid 和 stop_server](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000284535) ![有帮助](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) 咨询热线