Memory allocation
System tenant
The system tenant (sys tenant) is automatically created during the installation of OceanBase Database. In OceanBase Database of a version earlier than V4.2.1, the maximum memory available for the sys tenant was determined by sys_unit_config.memory_size. Starting from V4.2.1, the maximum memory available for the sys tenant is calculated as hidden_sys_memory + sys_unit_config.memory_size.
where:
The value of sys_unit_config.memory_size is determined by
memory_sizein thesys_unit_configresource specification.sys_unit_configis the default resource specification for the system tenant and specifies the minimum memory resource as the default. As a normal tenant, the system tenant allows you to execute theALTER RESOURCEstatement to modify the value ofmemory_size.The value of hidden_sys_memory is controlled by the hidden parameter
_hidden_sys_tenant_memory. The default value of the hidden parameter_hidden_sys_tenant_memoryis 0G, which indicates that the system adaptively allocates the memory size for hidden_sys_memory according to certain rules. We recommend that you do not modify the value of the hidden parameter_hidden_sys_tenant_memory.
User tenant
The memory of a user tenant is defined by the memory_size parameter when a unit is created for the user tenant. The memory_size parameter specifies the overall memory size of the user tenant, which includes the memory of the user tenant itself and its corresponding meta tenant. When you create a user tenant, the minimum memory size allowed to be created is specified by the hidden parameter __min_full_resource_pool_memory, the default value of which is 5G, with a value range of [1073741824,+∞).
The memory of a user tenant and that of its corresponding meta tenant can be divided into MemStore for incremental data loading and KVCache cache. For more information about MemStore for incremental data loading, see Management of non-auto-scaling memory. For more information about KVCache cache, see Management of dynamically scalable memory.
Meta tenant
Memory resources cannot be shared between a meta tenant and a user tenant, and their memory resources must be isolated. By default, a meta tenant occupies 10% of the overall tenant specification. To ensure the normal operation of a meta tenant, its minimum memory specification is 512 M, with no maximum limit. The memory specification of a user tenant is calculated by subtracting that of a meta tenant from the overall tenant memory specification. The minimum overall tenant memory specification is adjusted to 1 G. Here are some examples:
When the overall tenant specification is greater than or equal to 10 G, the memory specification ratio between a meta tenant and a user tenant is 1:9.
When the overall tenant specification is greater than or equal to 2 G, the memory specification of a meta tenant is fixed at 1 G, and the remaining resources are allocated to user tenants.
When the total size of memory of a user tenant is greater than or equal to 1 GB and smaller than 2 GB, the size of memory for the meta tenant is fixed at 512 MB, and the rest memory is for the user tenant.
Memory management
OceanBase Database divides the memory of each tenant into the following two categories:
Non-auto-scaling memory
Auto-scaling memory (KVCache)
The non-auto-scaling memory is intended for a MemStore, which stores incremental data. The auto-scaling memory is managed by a KVCache (including row_cache and schema_cache).
In addition, many memory components, including the plan cache (for caching execution plans) and SQL Area (memory for SQL statement execution), and some actions such as election, occupy a specific amount of memory resources. You can query the oceanbase.GV$OB_MEMORY view to check the usage of all memory components.
Memory management for non-auto-scaling memory
memstore_limit_percentage and ob_sql_work_area_percentage are the only parameters related to the non-auto-scaling memory. The former specifies the maximum percentage of the MemStore memory to the total memory of the tenant. The latter specifies the maximum size of memory occupied by the workspace of SQL blocking operators.
Data writes and updates in the tenant increase the MemStore usage. When the MemStore usage reaches the upper limit, subsequent write or update operations are denied.
OceanBase Database determines when to perform minor compaction or major compaction to release MemStore memory based on the memory usage ratio of the MemStore. This ratio is controlled by the parameter freeze_trigger_percentage, which specifies the percentage of the MemStore memory limit at which a freeze (the preliminary step before minor compaction) is triggered. By default, this value is set to 20% of the tenant’s MemStore memory limit.
Manage auto-scaling memory
A KVCache uses the memory other than the non-auto-scaling memory if possible. When the tenant memory is used up, the memory that is not referenced in the KVCache is first evicted to free up some space.
OceanBase Database manages most caches in the key-value (KV) format in KVCaches. KVCaches support auto-scaling, priority control for different cache types, and intelligent eviction mechanisms.
Generally, you do not need to configure a KVCache. In special scenarios, you can set the priorities for different cache types. Data of a cache type with a higher priority is more likely to be retained in the cache than data of a cache type with a lower priority.
The following table describes the parameters for controlling the priorities of different cache types. A greater value indicates a higher priority.
| Parameter | Description |
|---|---|
| tablet_ls_cache_priority | The priority of tablet_ls_cache in the cache system. |
| index_block_cache_priority | The priority of index_block_cache in the cache system. |
| user_block_cache_priority | The priority of user_block_cache in the cache system. |
| user_row_cache_priority | The priority of user_row_cache in the cache system. |
| bf_cache_priority | The priority of Bloom Filter in the cache system. |
| fuse_row_cache_priority | The priority of fuse_row_cache in the cache system. |
| opt_tab_stat_cache_priority | The priority of opt_tab_stat_cache in the cache system. |
You can query the oceanbase.GV$OB_KVCACHE view for information about different types of caches in KVCache. The key components of sys tenant and a normal tenant are slightly different:
Cache types in the
systenantCategory Description schema_cache Stores user schemas and the metadata of database objects required for SQL statements and the normal operation of the system. tablet_table_cache Caches the mappings between schema versions and table IDs in tablets. vtable_cache Caches the location information of tables. index_block_cache Caches microblock indexes to accelerate the access to microblock data. user_block_cache Caches microblock data. To improve query performance, the cache stores decompressed microblock data, which may be compressed by a compression algorithm. user_row_cache Caches hot row data in a table. bf_cache Caches Bloom filters for macroblocks whose query results are empty for a specified number of times. This improves the efficiency of filtering empty queries. fuse_row_cache Caches snapshot data of rows to improve the performance of point queries and avoid cache invalidation caused by minor and major compactions. opt_table_stat_cache Caches statistics such as the number of rows, macroblocks, and microblocks in a partition. opt_column_stat_cache Caches statistics such as the number of empty values, non-empty values, maximum value, and minimum value of a column in a partition. Cache types in a normal tenant
Category Description index_block_cache Caches microblock indexes to accelerate the access to microblock data. user_block_cache Caches microblock data. To improve query performance, the cache stores decompressed microblock data, which may be compressed by a compression algorithm. user_row_cache Caches hot row data in a table. bf_cache Caches Bloom filters for macroblocks whose query results are empty for a specified number of times. This improves the efficiency of filtering empty queries. fuse_row_cache Caches snapshot data of rows to improve the performance of point queries and avoid cache invalidation caused by minor and major compactions. tmp_block_cache Caches temporary files as a write buffer and write cache. tmp_page_cache Caches temporary files as a read cache. opt_table_stat_cache Caches statistics such as the number of rows, macroblocks, and microblocks in a partition. opt_column_stat_cache Caches statistics such as the number of empty values, non-empty values, maximum value, and minimum value of a column in a partition.