首批通过分布式安全可靠测评,为关键业务系统打造
租户内部内存管理
更新时间:2026-04-10 11:58:01
内存分配
系统租户
系统租户是 OceanBase 数据库的集群管理员为安装 OceanBase 数据库时自动创建。V4.2.1 版本前,系统租户实际可使用的内存上限为 sys_unit_config.memory_size。从 V4.2.1 版本开始,系统租户实际可使用的内存上限为:hidden_sys_memory + sys_unit_config.memory_size。
其中:
sys_unit_config.memory_size 的值由资源规格
sys_unit_config中的memory_size决定。sys_unit_config是系统租户默认的资源规格,其默认的内存资源为最小资源。由于系统租户也是一个正常的租户,故可以通过ALTER RESOURCE语句修改sys_unit_config中memory_size的值。hidden_sys_memory 的值由隐藏配置项
_hidden_sys_tenant_memory控制。隐藏配置项_hidden_sys_tenant_memory的默认值为 0G,表示系统会按照一定的规则进行自适应分配 hidden_sys_memory 的值。不建议修改隐藏配置项_hidden_sys_tenant_memory的值。
用户租户
用户租户内存由租户创建 Unit 时其 memory_size 的大小定义的,memory_size 为用户租户的整体内存大小,其内存包含用户租户本身的内存和其对应 Meta 租户的内存。在创建用户租户时,其允许创建的最小内存由隐藏配置项 __min_full_resource_pool_memory 控制,其默认值为 5G,取值范围为 [1073741824,+∞)。
用户租户本身的内存和其对应的 Meta 租户的内存可以分为装载增量数据的 MemStore 以及 KVCache 缓存。关于装载增量数据的 MemStore 的详细内容,参见 不可动态伸缩的内存管理,关于 KVCache 缓存的详细内容,参见 可动态伸缩的内存管理。
Meta 租户
Meta 租户的内存资源不支持共享,Meta 租户和用户租户的内存资源需要隔离。默认 Meta 租户占整体租户规格的 10%。为了保证 Meta 租户正常运行,Meta 租户内存资源规格最小为 512M,不设最大值。整体租户内存规格减去 Meta 租户内存规格即为用户租户的内存规格。整体租户规格最小值调整为 1G。下面举例说明:
租户规格大于等于 10G 时,Meta 租户和用户租户内存规格比例为 1:9。
租户规格大于等于 2G 时,Meta 租户的内存规格固定为 1G,剩余资源给用户租户。
租户规格小于 2G 时,Meta 租户固定分配 512M,剩余资源给用户租户。
租户规格最小 1G,Meta 租户占用 512M,用户租户占用 512M。
内存管理
OceanBase 数据库把租户内部的内存总体上分为以下两个部分:
不可动态伸缩的内存
可动态伸缩的内存——KVCache
其中,不可动态伸缩的内存主要给保存数据库增量更新的 MemStore 使用,可动态伸缩的内存主要由 KVCache(含 row_cache、schema_cache 等)进行管理。
除此之外,还有很多内存组件,包括 Plan Cache(执行计划缓存)、SQL Area(SQL 执行期内存)、选举动作等,都要占用一定量的内存。您可以通过查询 oceanbase.GV$OB_MEMORY 视图来获取所有内存组件的使用情况。
不可动态伸缩的内存管理
目前与不可动态伸缩内存相关的配置只有 memstore_limit_percentage 和 ob_sql_work_area_percentage,前者表示租户的 MemStore 部分最多占租户总内存上限的百分比,后者表示 SQL 阻塞算子工作区内存占用上限。
租户的写入或者更新会增加 MemStore 的内存使用,当租户的 MemStore 部分内存到达上限以后,后续的写入或者更新操作将会被拒绝。
OceanBase 数据库会根据 MemStore 的内存使用比例决定何时进行转储或者合并释放 MemStore 的内存,该比例由配置项 freeze_trigger_percentage 控制,表示当 MemStore 内存占用到达其上限的百分比后就进行冻结(转储的前置动作),默认值为租户 MemStore 内存上限的 20%。
可动态伸缩的内存管理
可动态伸缩的 KVCache 会尽量使用除去不可动态伸缩后租户的全部内存,当租户内存满时,会优先从 KVCache 中淘汰未被引用的内存来使用。
OceanBase 数据库将绝大多数的 KV 格式的缓存统一在了 KVCache 中进行管理,KVCache 支持动态伸缩、不同类型 Cache 的优先级控制以及智能的淘汰机制。
KVCache 一般不需要配置,特殊场景下可以通过参数控制各种 Cache 的优先级,优先级高的 Cache 比优先级低的 Cache 更容易被保留在 Cache 中。
用于控制不同类型 Cache 的优先级的参数如下表所示。参数值越大表示优先级越高。
| 参数 | 含义 |
|---|---|
| tablet_ls_cache_priority | tablet_ls_cache 在缓存系统中的优先级。 |
| index_block_cache_priority | index_block_cache 在缓存系统中的优先级。 |
| user_block_cache_priority | user_block_cache 在缓存系统中的优先级。 |
| user_row_cache_priority | user_row_cache 在缓存系统中的优先级。 |
| bf_cache_priority | Bloom Filter 在缓存系统中的优先级。 |
| fuse_row_cache_priority | fuse_row_cache 在缓存系统中的优先级。 |
| opt_tab_stat_cache_priority | opt_tab_stat_cache 在缓存系统中的优先级。 |
KVCache 中不同类型的 Cache 的信息可以通过查询 oceanbase.GV$OB_KVCACHE 视图获得。其中 sys 租户和普通租户的重要组成部分略有不同:
sys 租户上常见的 Cache 种类
类别 说明 schema_cache 存放用户的 Schema 信息,用于提供 SQL 及系统正常运行所依赖的数据库对象的元信息。 tablet_table_cache 缓存 Tablet 中 schema version 和 table id 的对应关系。 vtable_cache 缓存 Table 的 Location 信息。 index_block_cache 缓存微块的 Index,加速微块数据的访问。 user_block_cache 缓存微块数据,由于微块可能通过压缩算法进行压缩,为了提升查询性能,缓存的是解压后的微块数据。 user_row_cache 缓存某一个 Table 中的热点行数据。 bf_cache 缓存为点查结果为空且超过一定次数的宏块建立的 Bloomfilter,用于提高空查询的过滤效率。 fuse_row_cache 缓存行的快照点数据,用于提高点查询性能,并且可以避免因转储、合并导致的缓存失效问题。 opt_table_stat_cache 缓存某一个分区的统计信息,例如行数、宏块数、微块数等。 opt_column_stat_cache 缓存分区中某一列的统计信息,例如空值数、非空值数、最大值、最小值等。 普通租户上常见的 Cache 种类
类别 说明 index_block_cache 缓存微块的 Index,加速微块数据的访问。 user_block_cache 缓存微块数据,由于微块可能通过压缩算法进行压缩,为了提升查询性能,缓存的是解压后的微块数据。 user_row_cache 缓存某一个 Table 中的热点行数据。 bf_cache 缓存为点查结果为空且超过一定次数的宏块建立的 Bloomfilter,用于提高空查询的过滤效率。 fuse_row_cache 缓存行的快照点数据,用于提高点查询性能,并且可以避免因转储、合并导致的缓存失效问题。 tmp_block_cache 缓存临时文件,作为写缓冲区以及写缓存。 tmp_page_cache 缓存临时文件,作为读缓存。 opt_table_stat_cache 缓存某一个分区的统计信息,例如行数、宏块数、微块数等。 opt_column_stat_cache 缓存分区中某一列的统计信息,例如空值数、非空值数、最大值、最小值等。