--- title: "产品 FAQ - OceanBase 数据库 V4.6.0 | OceanBase 文档中心" description: 产品 FAQ 产品架构和特点 FAQ 我需要一个实例还是多个实例？ 如果有多个子系统，每个子系统在数据库层面没有交互，建议每个子系统使用不同的实例。 用户如何使用 OceanBase 数据库？ 和传统数据库一样，OceanBase 数据库提供了 SQL 接口，用户可以通过 SQL 语言访问、操作数据库。 OceanB… --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.6.0 # 产品 FAQ 更新时间：2026-05-26 15:39:13 [编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.6.0/zh-CN/800.FAQ/100.oceanbase-products-faq.md) ## 产品架构和特点 FAQ ### 我需要一个实例还是多个实例？ 如果有多个子系统，每个子系统在数据库层面没有交互，建议每个子系统使用不同的实例。 ### 用户如何使用 OceanBase 数据库？ 和传统数据库一样，OceanBase 数据库提供了 SQL 接口，用户可以通过 SQL 语言访问、操作数据库。 ### OceanBase 数据库与 JPA 冲突吗？ JPA（Java Persistence API）是 Java 标准中的一套 ORM 规范，借助 JPA 技术可以通过注解或者 XML 来描述对象与关系表之间的映射关系，并将实体对象持久化到数据库中（即完成 Object Model 与 Data Model 间的映射）。而 OceanBase 数据库是阿里巴巴和蚂蚁集团不基于任何开源产品，完全自研的原生分布式关系型数据库软件。两者不冲突。 ### 数据文件对应哪个级别的数据库管理？ OceanBase 数据库中目前有两类数据文件，且两类数据文件均属于集群级别： - Data 文件：保存各个分区的数据，包括各个分区的 Checkpoint 点。 - clog 相关：包含 clog（也称为 `Redo Log` 或 WAL 日志） 和它的索引文件。 ### OceanBase 数据库是如何支持 HTAP 的？ OceanBase 数据库自创的分布式计算引擎，能够让系统中多个计算节点同时运行 OLTP 类型的应用和复杂的 OLAP 类型的应用，真正实现了用一套计算引擎同时支持混合负载的能力，让用户通过一套系统解决 80% 的问题，充分利用用户的计算资源，节省用户购买额外的硬件资源、软件授权带来的成本。 ### 什么是实例，什么是租户，它们的关系是什么？ OceanBase 数据库是一个多租户系统，一个实例即 OceanBase 集群中的一个租户。租户之间的数据不能互相访问。 ### OceanBase 数据库的性能和机器数量的关系是什么？ 从 OceanBase 数据库的 TPC-C 报告中显示，相同场景下的基本都是线性扩展的。 ### 使用 OceanBase 数据库在开发中要特别注意什么？ 以下列出开发过程中的注意事项，仅供参考： - 大数据量导入需要特别关注内存的使用情况。 - 索引生效时间较长，建议在建表时将索引语句一并纳入。 - mysql-connector-java 的版本建议使用 5.1.30 及以上。 - 列类型修改有较大限制。Varchar 长度只能由短变长，不能由长变短。 - 如果一个连接超过 15 分钟空闲，服务端会主动断开，在使用连接池的时候需要设置一个连接最大的空闲时间。例如，Druid 的 `minEvictableIdleTimeMillis` 小于 15 分钟。 ### OceanBase 数据库是如何做到比传统数据库更省空间的？ OceanBase 数据库通过数据编码压缩技术实现高压缩。数据编码是基于数据库关系表中不同字段的值域和类型信息，所产生的一系列的编码方式，它比通用的压缩算法更懂数据，从而能够实现更高的压缩效率。 ### OceanBase 数据库做 AP 能力处理所需的数据量大概多少？ 具体根据业务需求 100 G 到 PB 级不设限。AP 是 OceanBase 数据库提供的一个能力。数据量较小时，把并行设置小一些，用的计算资源就小；数据规模较大时，计算资源设置多一些。本质上并没有一个量的限制。AP 的能力，主要体现在把机器硬件资源充分调动起来的能力，以及生成高效的并行计划等方面的能力。 ### OceanBase 数据库最新版本中对标准 SQL 的支持度是多少？ 在实际应用场景中，MySQL 模式的大部分业务均能够做到平滑迁移；Oracle 模式下基本的 Oracle 功能也都支持，只需要很少的改动就可以平滑地由 Oracle 数据库迁移到 OceanBase 数据库。 ### 以前运行在 MySQL 上的业务，迁移到 OceanBase 数据库上的成本如何？ OceanBase 数据库兼容常用 MySQL 功能及 MySQL 前后台协议，业务零修改或少量修改即可从 MySQL 迁移至 OceanBase 数据库。 ### OceanBase 数据库作为一个以 TP 见长的数据库，AP 计算能力怎么样呢？ AP 主要采用行列混合存储、编译执行、向量引擎、基于代价的查询改写和优化等技术，再加上 OceanBase 数据库良好的可扩展性，OceanBase 数据库在 AP 领域里面的实时分析能力都是业界领先的。此外，对于离线大数据处理，Spark 等大数据方案也是更合适的选择。 ### OceanBase 数据库作为一款分布式数据库，业务 APP 连接数据库时和传统数据库是否有不同？ OceanBase 数据库作为分布式数据库，副本可能分布在不同的机器上，为了尽可能地减少跨机数据访问，OceanBase 数据库提供了 obproxy。obproxy 作为 OceanBase 分布式关系数据库专用反向代理服务器, 为前端用户请求提供了高性能、高准确率的路由转发服务, 为后端 Server 服务提供了高可用易扩展的容灾保障. 相对于其他数据库的代理服务器, obproxy 根据实际单机环境和 OceanBase 多集群部署的特点, 采用异步框架和流式转发的设计, 采用 FastParse 和 LockFree 的内存方案, 具备有限资源占用下百万 QPS 的能力和海量部署下丰富便捷的运维支持能力。 ### OceanBase 数据库的技术架构有哪些技术特点？ OceanBase 数据库作为一款原生的分布式数据库，有以下技术特点： - 弹性扩展 OceanBase 数据库支持在线弹性扩展，当集群存储容量或是处理能力不足时，可以随时加入新的 OBServer，系统自动进行数据迁移，根据机器的处理能力，将合适的数据分区迁移到新加入的机器上；同样在系统容量充足和处理能力富余时，也可以将机器下线，降低成本。比如在双 11 大促之类的活动中，可以提供良好的弹性伸缩能力。 - 负载均衡能力 OceanBase 数据库管理着许多台 OBServer 节点形成一个 OBServer 集群为多个租户提供数据服务。OceanBase 集群管控的所有 OBServer 节点可以被视为一个超级大的“资源蛋糕”，在分配资源时，按需分配给创建租户时申请的资源。OceanBase 数据库的负载均衡能力能够保证多个租户在整个 OBServer 集群中申请的资源占用相对均衡，并且在动态场景下（比如添加删除 OBServer、 添加删除租户、增删过程中分区数据量发生倾斜等场景），负载均衡算法仍然能在已有的节点上平衡资源。 OceanBase 数据库通过 Root Service 管理各个节点间的负载均衡。不同类型的副本需求的资源各不相同，Root Service 在执行分区管理操作时需要考虑的因素包括每台 OBServer 节点上的 CPU、磁盘使用量、内存使用量、IOPS 使用情况；避免同一张表格的分区全部落到少数几台 OBServer；让耗内存多的副本和耗内存少的副本位于同一台机器上；让占磁盘空间多的副本和占磁盘空间少的副本位于同一台机器上。经过负载均衡，最终会使得所有机器的各类型资源占用都处于一种比较均衡的状态，充分利用每台机器的所有资源。 - 分布式事务 ACID 能力 OceanBase 数据库架构下事务的 ACID 的实现方式是： - Atomicity：使用两阶段提交保证快照事务原子性。 - Consistency：保证事务的一致性。 - Isolation：使用多版本机制进行并发控制。 - Durability：事务日志使用 Paxos 协议做多副本同步。 - 高可用 OceanBase 数据库中的每个分区都维护了多个副本，这些分区的多个副本之间通过 Paxos 协议进行日志同步。每个分区和它的副本构成一个独立的 Paxos 组，其中一个副本为主（Leader），其它副本为备（Follower）。每台 OBServer 服务的一部分分区为 Leader，一部分分区为 Follower。当 OBServer 节点出现故障时，Follower 分区不受影响，Leader 分区的写服务短时间内会受到影响，直到通过 Paxos 协议将该分区的某个 Follower 选为新的 Leader 为止，整个过程不超过 30s。通过引入 Paxos 协议，可以保证在数据强一致的情况下，具有极高的可用性及性能。 同时 OceanBase 数据库也支持主备库架构。OceanBase 集群的多副本机制可以提供丰富的容灾能力，在机器级、机房级、城市级故障情况下，可以实现自动切换，并且不丢数据（即 RPO = 0）。当主集群出现计划内或计划外（多数派副本故障）的不可用情况时，备集群可以接管服务，并且提供无损切换（RPO = 0）和有损切换（RPO > 0）两种容灾能力，最大限度降低服务停机时间。 OceanBase 数据库支持创建、维护、管理和监控一个或多个备集群。备集群是生产库数据的热备份。管理员可以选择将资源密集型的报表操作分配到备集群，以便提高系统的性能和资源利用率。 - 高效的存储引擎 OceanBase 数据库的存储引擎基于 LSM-Tree 架构，数据被划分为MemTable（也称作 MemStore） 和 SSTable 两部分。其中 MemTable 提供读写，而 SSTable 是只读的。用户插入/删除/更新的数据先写入 MemTable，通过 Redo Log 来保证事务性，Redo Log 会在三副本间使用 Paxos 协议进行同步，当单台 Server 宕机时，通过 Paxos 协议保证数据的完整性，并通过较短的恢复时间来保证数据的高可用。 当 MemTable 的大小超过一定的阈值时，需要将 MemTable 中的数据转存到 Mini SSTable 中以释放内存，该过程称为 Mini Compaction。随着用户数据的写入，Mini SSTable 的数量越来越多，当 Mini SSTable 的数量超过一定的阈值时，后台会自动触发 Minor Compaction。转储（Mini Compaction）会生成新的 Mini SSTable。当转储（Mini Compaction）的次数超过一定阈值时，或者在每天的业务低峰期，系统会将基线 SSTable（Major SSTable）与之后转储的增量 SSTable（Mini/Minor SSTable）合并为一个新的 Major SSTable，该过程称为合并。OceanBase 数据库通过转储和合并的过程，优化了数据存储空间的基础，提供了高效的读写服务，保证事务性和数据的完整性。 - 多租户 OceanBase 数据库是一个支持多租户的分布式数据库，一个集群支持多个业务系统，也就是通常所说的多租户特性。 多租户的架构优势在于可以充分利用系统资源，使得同样的资源可以服务更多的业务。通过将波峰、波谷期不同的业务系统部署到一个集群，以实现对系统资源最大限度的使用。在租户的应用方面，保证了租户之间的隔离性；在数据安全方面，不允许跨租户的数据访问，确保用户的数据资产没有泄露的风险；在资源使用方面，租户“独占”其资源配额，该租户对应的前端应用，无论是响应时间还是 TPS/QPS 都比较平稳，不会受到其他租户负载轻重的影响。 - Oracle 兼容和 MySQL 兼容 OceanBase 数据库支持 Oracle 兼容模式和 MySQL 兼容模式，用户可以根据不同的需要选择不同的模式。 ## 内存 FAQ ### OceanBase 数据库有哪些内存区域？ OceanBase 数据库中主要有以下内存区域： - `kv cache`：`LSM-Tree` 中 SSTable 及数据库表模式等的缓存。 - `memory store`：`LSM-Tree` 中的 `MemStore` 的内存。 - `sql work area`：租户执行 SQL 过程中各个 Operator 工作区占用的内存，超出部分通常会走落盘流程。 - `system memory`：预留给 `Net IO`、`Disk IO`、`Election` 与负载均衡等各种功能的内存。 ### OceanBase 数据库的资源在租户中哪些是共享的，哪些是不共享的？ 对内存而言，`sql work area、memory store` 与 `kv cache` 等资源为租户独享；`system memory` 为多个租户共享。对线程而言，`sql worker` 为租户间隔离；`Net IO`、`Disk IO` 与 `clog Writer` 等资源为租户间不隔离。 ### OceanBase 数据库的内存使用有什么特征？ OceanBase 数据库在启动时会需要加载大约几个 GB 的内存，在运行过程中会逐渐按需进一步申请内存直至 `memory_limit`。而一旦 OBServer 节点向 OS 进行了内存申请，通常是不会释放或者返回给 OS，而是会维护在内存管理的使用列表和 `Free List` 当中。这个是 OceanBase 数据库设计上所建立的内存管理机制。 ### 运行一段时间后，OceanBase 数据库使用内存接近 memory_limit 是否正常？ 在 OceanBase 数据库的集群运行一段时间以后，内存消耗接近于 `memory_limit` 水平位置，且不发生降低的现象是符合预期的。 有一个例外是若设置了参数 `memory_chunk_cache_size`，OBServer 节点会尝试将 Free List 超过 `memory_chunk_cache_size` 的内存块还给 OS，增大 Free List 在 OceanBase 数据库内部的复用率，减少 RPC 由于内存操作慢而导致超时的风险。通常情况是不需要配置 `memory_chunk_cache_size` 的，在特定的场景下需要与 OceanBase 数据库 支持进行场景分析确定是否需要动态调整 `memory_chunk_cache_size`。 ### OBServer 节点的内存上限是否可以动态调整？ OBServer 节点的内存上限可以通过调整 `memory_limit` 或 `memory_limit_percentage` 来动态实现。需要注意的是调整前要检查内存资源是否够用，OBServer 节点内存上限目标是否已经低于了所有租户以及 500 租户的内存分配（租户建立时分配）的总和。`memory_limit` 的单位是 MB，例如，如果需要通过调整 `memory_limit` 参数来调整 OBServer 节点内存上限为64G，可以通过语句 `memory_limit ='64G'` 或者通过 `memory_limit = 65536` 来指定。 另一方面，在使用 OBServer 节点的过程中，可能通过 `memory_limit` 来限制 OBServer 节点内存的生效参数。若将 `memory_limit` 设置为 0，还可以通过 `memory_limit_percentage` 以比例的形式更灵活地约束 OBServer 节点内存的使用情况。 ### 在使用 OceanBase 数据库定义资源单元以及资源池时是否允许内存超卖？ 在 OceanBase 数据库 V4.x 版本中，不再支持内存超卖，引入内存超卖可能会导致租户工作不稳定。 ### OceanBase 数据库进行一次内存分配会检查哪些限制？ OceanBase 数据库内核限制了单次的内存申请不能超过 4G，这个限制并非是对用户可见的。而是为了内存的优化使用和避免不合理的内存分配在内核中添加的限制。除此之外 OceanBase 数据库内核中每次进行内存申请还会进行如下检查，在出现相应的报错时，请根据对应的报错信息来具体分析： | **内存限制** | **observer.log 日志中报错关键字** | **问题排查思路** | | --- | --- | --- | | 租户下某个上下文（context)上限 | `ctx memory has reached upper limit` | 当前租户下某个 context 达到上限，此时需要查看在这个上下文中有哪些 mod 占用异常。只有部分 context 有这种限制, 如 `WORK_AREA`，其他的 context 模块与其他内存一起共同受到租户内存的 `limit` 约束。 | | 租户的内存上限 | `tenant memory has reached the upper limit` | 当前租户的内存使用达到上限，需要查看当前租户的哪些上下文内存占用超出预期，找到后再继续细分。 | | OceanBase 数据库内存上限 | `server memory has reached the upper limit` | OceanBase 数据库的内存总和达到上限，此时需要查看哪些租户内存占用超出预期，找到后再继续细分。 | | 物理内存上限 | `physical memory exhausted` | 一般是从物理内存申请不足导致，通常与部署方式以及参数有关。此时需要查看物理内存的大小、`observer memory_limit` 的配置、物理机上运行的 OBServer 节点个数以及其他消耗内存的进程的部署，通过这个的方式来拆解整个物理内存的消耗情况。 | ### OceanBase 数据库的 KVCache 有哪些，分别有什么作用？ 对于 OceanBase 数据库的 KVCache 可以通过 `GV$OB_KVCACHE` 视图进行查询，大体上有一下几种： - `BloomFilter Cache`：OceanBase 数据库的 BloomFilter 是构建在宏块上的，按需自动构建，当一个宏块上的空查次数超过某个阈值时，就会自动构建 BloomFilter，并将 BloomFilter 放入 Cache。 - `Row Cache`：缓存具体的数据行，在进行 Get/MultiGet 查询时，经常会将对应查到的数据行放入 `Row Cache`，这样在进行热点行的查询时，就能极大地提升查询性能。 - `Block Index Cache`：缓存微块的索引，类似于 Btree 的中间层，由于中间层通常不大，`Block Index Cache` 的命中率通常都比较高。 - `Block Cache`：OceanBase 数据库的 `Buffer Cache`，缓存具体的数据块，实际上 `Block Cache` 中缓存是解压后的微块。 - `Partition Location Cache`：用于缓存 Partition 的位置信息，来帮助对一个查询进行路由。 - `Schema Cache`：缓存数据表的元信息，用于执行计划的生成以及后续的查询。 - `clog Cache`：缓存 clog 数据，用于加速某些情况下 Paxos 日志的拉取。 ### KV Cache 如何做到的动态伸缩，以及有什么样的淘汰规则？ 可动态伸缩的内存主要部分是 KV Cache，而 OceanBase 数据库将绝大多数的 KV 格式的缓存统一在了 KV Cache 中进行管理。 KV Cache 一般不需要配置，特殊场景下可以通过参数控制各种 KV 的优先级，优先级高的 KV 类比优先级低的 KV 类更容易被保留在 Cache 中。若要调整默认的 KV Cache 相关优先级的默认配置，需要联系 OceanBase 数据库技术支持工程师。 ### OceanBase 数据库内存有哪些常见问题，可能导致的原因是什么？ OceanBase 数据库内存有如下常见问题： - 工作区（work area）报内存不足 工作区内存 `limit = 租户内存 * ob_sql_work_area_percentage（默认5%）`，如果请求并发量较大，且每个请求占用的工作区内存比较多，可能出现工作区内存不足的报错。经常出现的场景有 union、sort、group by 等。 可以通过适当调大工作区系统变量来规避，比如 `set global ob_sql_work_area_percentage = 10`。 - 模块的内存超限 客户端报错 `"Over tenant memory limits"`，错误码 4030。通常需要进一步分析当前内存消耗的情况。 可以通过 `GV$OB_MEMORY` 视图，也可通过 `observer.log` 中的日志查看是哪个 mod 消耗的内存绝对占比比较大。 - MemStore 内存用尽 写入的速度大于转储的速度，导致 MemStore 耗尽。比如：大量高并发的数据导入，MemStore 的写操作过快，系统未能及时转储，MemStore 就被用完，返回用户报错 4030。 可以通过分析转储速度缓慢瓶颈、尝试提高转储速度，或者是减缓写入速度来减缓、解决这类问题。 - OBServer 节点整体内存使用超限 OBServer 节点进程在启动过程中，会根据配置的参数来计算当前进程最大使用的物理内存上限。如果 `memory_limit` 配置数值，那么 OBServer 节点的内存会直接取 `memory_limit`。如果 `memory_limit` 为 0，则会通过 `物理内存 * memory_limit_percentage` 来计算得到内存使用上限。 若观察到 OBServer 节点内存使用超限，可以查询 `_all_virtual_server_stat` 可以看到实际的 OBServer 节点内的 limit, 然后再次检查 `memory_limit`、`memory_limit_percentage` 这两个参数是否配置正确。如果还存在内存超限且整体趋势持续增长的情况，那么有可能是遇到了内存泄露的场景，需要联系 OceanBase 数据库技术支持工程师来进行排查解决。 ## 多租户线程 FAQ ### OceanBase 数据库在运行过程中是单进程还是多进程？ OceanBase 数据库是单进程数据库，运行过程中的主要线程如下： - `election worker`：选举线程。 - `net io`：处理网络 I/O 的线程。 - `disk io`：处理磁盘 I/O 的线程。 - `clog writer`：写 clog 的线程。 - `misc timer`：包括多个后台定时器线程，主要负责清理资源。 - `compaction worker`：处理 Minor Merge、Major Merge 的线程。 - `sql worker` 与 `transaction worker`：处理 SQL 和事务请求的线程。 ### OBServer 节点有哪些后台线程，主要是做什么用的？ 在大部分场景下，用户无需关注后台线程实现细节。在 OBServer 节点版本迭代中，后台线程也会出现更新的情况。 如下列举出 OBServer 节点的部分常见后台线程，以及其相关功能介绍。 | 线程名 | 级别 | 归属模块 | 线程数量 | 功能描述 | | --- | --- | --- | --- | --- | | FrzInfoDet | 租户 | 事务 | 2 | 周期性检查是否有新的 freeze_info | | LockWaitMgr | 租户 | 事务 | 1 | 用于周期性检查超时时间，唤醒等锁的事务 | | TenantWeakRe | 租户 | 事务 | 1 | 租户级别备机读时间戳生成线程 | | TransService | 租户 | 事务 | 1 | 处理事务模块内部若干后台处理的异步任务，推 Ls 的 Checkpoint 等 | | TransTimeWhe | 租户 | 事务 | max(cpu_num/24, 2) | 处理事务 2PC 流程的定时任务 | | TsMgr | 进程 | 事务 | 1 | GTS 的后台任务处理线程：删除无用的租户，刷新各个租户的 GTS 等 | | TSWorker | 进程 | 事务 | 1 | 处理远程 GTS 访问返回的结果，回调事务 | | TxLoopWorker | 租户 | 事务 | 1 | 事务模块后台定时任务 | | ArbSer | 进程 | 系统 | 1 | 仲裁 Server 定时从配置文件加载配置参数 | | Blacklist | 进程 | 系统 | 2 | 负责探测与通信目的端 Server 之间的网络是否联通 | | ConfigMgr | 进程 | 系统 | 1 | 用于配置项的刷新 | | L0_G0 | 租户 | 系统 | 2+min_cpu * cpu_quota_concurrency | 处理大部分该租户请求 | | L2_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 2 的请求 | | L3_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 3 的请求 | | L4_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 4 的请求 | | L5_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 5 的请求 | | L6_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 6 的请求 | | L7_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 7 的请求 | | L8_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 8 的请求 | | L9_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 9 的请求 | | LuaHandler | 进程 | 系统 | 1 | 处理应急场景的 Lua 请求以读取 observer 进程内部状态 | | MemDumpTimer | 进程 | 系统 | 1 | 定时打印 MEMORY 日志 | | MemoryDump | 进程 | 系统 | 1 | 定时统计内存信息 | | MultiTenant | 进程 | 系统 | 1 | 负责刷多租户 CPU 配比，用于资源调度 | | OB_PLOG | 进程 | 系统 | 1 | 异步打印 observer 进程诊断日志 | | pnio | 进程 | 系统 | 由 net_thread_count 配置的参数决定 | 新网络框架 pkt-nio 的网络 IO 线程 | | pnlisten | 进程 | 系统 | 1 | 监听 RPC 端口以及转发 RPC 连接到网络 IO 线程 | | SignalHandle | 进程 | 系统 | 1 | 信号处理线程 | | SignalWorker | 进程 | 系统 | 1 | 异步处理信号线程 | | L0_G2 | 租户 | 选举 | min_cpu，最少 8 个 | 专门处理选举请求的线程 | ### OBServer 节点的多租户架构中如何做到 CPU 资源的有效隔离？ 在 OBServer 节点目前发布的版本中，OBServer 节点主要是依靠控制活跃线程数量（实际消耗 CPU 资源的线程）来控制 CPU 消耗的。OBServer 节点在创建租户的时候会指定租户资源池，资源池定义 `max_cpu` 可以限制的租户级别的最大活跃线程使用，从而做到租户间 CPU 使用的隔离。在 OBServer 节点的最新版本中，OBServer 节点内核实现了 cgroup 的隔离来对 CPU 内存和资源进行有效地控制和限制。 ### 如何读取 OBServer worker 线程的数量呢？OBServer 节点是否会在负载高的时候动态启动新的线程来执行负载呢？ 在 observer.log 中以关键字 `dump tenant info` 为主的日志片段里，会描述现在 worker 线程的现有值以及最大值。具体为下： ```sql tocken_count = 分配给该租户的 cpu_count (>min_cpu&&