Memory allocation
System tenant
The system tenant is automatically created by the cluster administrator when OceanBase Database is installed. Before V4.2.1, the maximum memory available to the system tenant was sys_unit_config.memory_size. In V4.2.1 and later, the maximum memory available to the system tenant is: hidden_sys_memory + sys_unit_config.memory_size.
Here:
The value of
sys_unit_config.memory_sizeis determined by thememory_sizeparameter in thesys_unit_configparameter, which specifies the resource specifications for the system tenant. The default value ofmemory_sizeis the minimum memory. Since the system tenant is also a normal tenant, you can use theALTER RESOURCEstatement to modify the value ofmemory_sizeinsys_unit_config.The value of
hidden_sys_memoryis controlled by the hidden parameter_hidden_sys_tenant_memory. The default value is 0 GB. This means that the system will adaptively allocate memory for_hidden_sys_tenant_memorybased on some rules. We recommend that you do not modify the value of_hidden_sys_tenant_memory.
User tenant
The memory of a user tenant is defined by the memory_size parameter when the tenant creates a unit. memory_size specifies the total memory size of the user tenant, which includes the memory of the user tenant itself and that of the corresponding meta tenant. When you create a user tenant, the minimum memory that you can create is controlled by the hidden parameter __min_full_resource_pool_memory, which default value is 5 GB, 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 loading incremental data and KVCache for caching. For more information, see [Memory management without dynamic scaling](#Memory management without dynamic scaling) and [Memory management with dynamic scaling](#Memory management with dynamic scaling).
Meta tenant
Memory resources are not 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 specifications of the corresponding user tenant. To ensure the normal operation of the meta tenant, the minimum memory specification of the meta tenant is 512 MB, with no maximum limit. The memory specifications of the user tenant are calculated by subtracting the memory specifications of the meta tenant from the overall tenant specifications. The minimum overall tenant specification is 1 GB. Here is an example:
When the overall tenant specification is greater than or equal to 10 GB, the memory specifications of the meta tenant and the user tenant are in the ratio of 1:9.
When the overall tenant specification is greater than or equal to 2 GB, the memory specification of the meta tenant is fixed at 1 GB, and the remaining resources are allocated to the user tenant.
When the overall tenant specification is less than 2 GB, 512 MB of memory is fixedly allocated to the meta tenant, and the remaining resources are allocated to the user tenant.
The minimum overall tenant specification is 1 GB. The minimum memory specification of the meta tenant is 512 MB, and that of the user tenant is 512 MB.
Memory management
OceanBase Database divides the memory of a tenant into the following two categories:
Non-dynamically scalable memory
Dynamically scalable memory, which is managed by KVCache (including row cache and schema cache)
The non-dynamically scalable memory is used to store incremental updates of the database by MemStore.
In addition, the following memory components are also used: plan cache (execution plan cache), SQL area (memory for SQL execution), and election actions. You can query the oceanbase.GV$OB_MEMORY view for more information about the memory usage of all components.
Memory management for non-dynamically scalable memory
Currently, the only configurations related to non-dynamically scalable memory are memstore_limit_percentage and ob_sql_work_area_percentage. The former specifies the maximum percentage of the tenant's total memory upper limit allowed for MemStores. The latter specifies the maximum amount of memory allowed for workspaces of SQL blocking operators.
Writes or updates increase the memory usage of MemStores. After the memory usage of the MemStore reaches the upper limit, subsequent writes or updates are denied.
OceanBase Database decides whether to initiate a minor or major compaction to release the memory space occupied by MemStores based on the memory usage ratio of MemStores. The ratio is specified by the freeze_trigger_percentage parameter. When the memory usage of MemStores reaches the upper limit of the specified percentage, the database initiates a freeze (a pre-minor compaction action). The default value is 20% of the upper limit of MemStore memory.
Dynamic memory management
The KVCache uses dynamic memory management. It tries to use all the memory except that of the tenant with fixed memory. When the memory of the tenant is full, the KVCache will prioritize evicting unused memory for the tenant.
OceanBase Database manages most of the cache data in the KV format in the KVCache and supports dynamic memory management, priority control of different types of cache, and intelligent memory eviction.
Generally, you do not need to configure the KVCache. In special scenarios, you can control the priorities of different types of cache through parameters. A cache with a higher priority is less likely to be evicted.
The following parameters are provided to control the priorities of different types of cache. A higher parameter value indicates a higher priority.
| Parameter | Description |
|---|---|
| tablet_ls_cache_priority | The priority of the tablet_ls_cache in the cache system. |
| index_block_cache_priority | The priority of the index_block_cache in the cache system. |
| user_block_cache_priority | The priority of the user_block_cache in the cache system. |
| user_row_cache_priority | The priority of the user_row_cache in the cache system. |
| bf_cache_priority | The priority of the Bloom Filter in the cache system. |
| fuse_row_cache_priority | The priority of the fuse_row_cache in the cache system. |
| opt_tab_stat_cache_priority | The priority of the opt_tab_stat_cache in the cache system. |
You can query the oceanbase.GV$OB_KVCACHE view for information about the different types of cache in the KVCache. The cache types in the sys tenant are different from those in a normal tenant:
Cache types in the
systenantCategory Description schema_cache Stores user schemas to provide metadata of database objects, such as those required for SQL and system operations. 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 indexes of microblocks to accelerate access to microblock data. user_block_cache Caches microblock data. Since microblocks can be compressed using a compression algorithm, the cache stores decompressed microblock data to enhance query performance. user_row_cache Caches hot rows in a table. bf_cache Caches Bloom filters built for macroblocks whose query results are empty for more than a specified number of times. This helps improve the filtering efficiency of empty queries. fuse_row_cache Caches snapshot data of rows to improve the performance of point queries, and avoids cache invalidation issues caused by minor compactions or major compactions. opt_table_stat_cache Caches statistics, such as the number of rows, macroblocks, and microblocks, of a partition. opt_column_stat_cache Caches statistics, such as the number of empty and non-empty values, as well as the maximum and minimum values, of a column within a partition. Cache types in a normal tenant
Category Description index_block_cache Caches indexes of microblocks to accelerate access to microblock data. user_block_cache Caches microblock data. Since microblocks can be compressed using a compression algorithm, the cache stores decompressed microblock data to enhance query performance. user_row_cache Caches hot rows in a table. bf_cache Caches Bloom filters built for macroblocks whose query results are empty for more than a specified number of times. This helps improve the filtering efficiency of empty queries. fuse_row_cache Caches snapshot data of rows to improve the performance of point queries, and avoids cache invalidation issues caused by minor compactions or major compactions. tmp_block_cache Caches temporary files as write buffers and write caches. tmp_page_cache Caches temporary files as read caches. opt_table_stat_cache Caches statistics, such as the number of rows, macroblocks, and microblocks, of a partition. opt_column_stat_cache Caches statistics, such as the number of empty and non-empty values, as well as the maximum and minimum values, of a column within a partition.