Memory allocation
sys tenant
The sys tenant is automatically created during the installation of OceanBase Database. Prior to OceanBase Database 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 the
sys_unit_config.memory_sizeparameter is determined by thememory_sizefield in thesys_unit_configparameter. Thesys_unit_configparameter specifies the default resource unit specifications of the sys tenant. The default values of fields of this parameter are the minimum resources required. You can also modify the value of thememory_sizefield in thesys_unit_configparameter by executing theALTER RESOURCEstatement.The value of the
hidden_sys_memoryparameter is determined by the hidden parameter_hidden_sys_tenant_memory. The default value of the_hidden_sys_tenant_memoryparameter is0G, which indicates that the system adaptively evaluates thehidden_sys_memoryparameter based on the specified rules. We recommend that you do not modify the value of the_hidden_sys_tenant_memoryparameter.
User tenant
The size of memory for a user tenant is specified by the memory_size parameter when the resource unit is created. The memory_size parameter specifies the overall size of the memory of the user tenant, which is the sum of the memory of the user tenant and the memory of the corresponding meta tenant. When a user tenant is created, the minimum memory size allowed is specified by the hidden parameter __min_full_resource_pool_memory. The value range is [1073741824,+∞). The default value is 5 GB.
Both the memory for a user tenant itself and the memory for its corresponding meta tenant consists of a MemStore for storing incremental data and a KVCache. For more information about MemStores and KVCaches, see Manage non-auto-scaling memory and Manage auto-scaling memory.
Meta tenant
The memory of a meta tenant cannot be shared and must be isolated from the memory of the corresponding user tenant. By default, the meta tenant occupies 10% of the overall tenant memory specification. To ensure the normal operation of the meta tenant, the meta tenant must have at least 512 MB of memory. The memory specification of the user tenant is the overall tenant memory specification minus the memory specification of the meta tenant. The minimum overall tenant memory specification is adjusted to 1 GB. Here are some examples:
When the total size of memory of a user tenant is greater than or equal to 10 GB, the ratio of the memory for the meta tenant to that of the user tenant is 1:9.
When the total memory of a user tenant is greater than or equal to 2 GB, the memory of the meta tenant is fixed at 1 GB, and the rest memory is for the user tenant.
When the total size of memory of a user tenant is 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.
When the minimum size of memory of a user tenant is 1 GB, each of the meta tenant and user tenant occupies 512 MB of memory.
Memory management
OceanBase Database classifies the internal memory of each tenant into two parts:
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.
Manage 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 default value is 50% of the total memory of the tenant, which is specified by memory_size. The latter specifies the maximum size of memory occupied by the workspace of SQL blocking operators. The default value is 5% of the total memory of the tenant.
Data writes and updates in the tenant will increase the MemStore usage. When the MemStore usage reaches the upper limit, subsequent write or update operations will be denied.
OceanBase Database triggers minor or major compactions based on the MemStore usage to release the MemStore memory. Specifically, when the MemStore usage reaches the value specified by the freeze_trigger_percentage parameter, OceanBase Database triggers a minor freeze, which is the preparation for a minor or major compaction. The default value of this parameter is 70%, which is also 35% of the total memory of the tenant.
Note
memory_size specifies the total memory of the tenant. You can configure the value based on the business situation.
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 the Bloom filter cache 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 cache types in the KVCache. The cache types of the sys tenant are slightly different from those of a user tenant.
The following table describes the cache types of the sys tenant.
Cache type Description schema_cache Stores the schema information of users and provides the metadata of database objects for the normal running of SQL statements and the system. tablet_table_cache Caches the mapping between schema versions and table IDs in tablets. vtable_cache Caches the location information of tables. index_block_cache Caches microblock indexes to speed up access to microblock data. user_block_cache Caches microblock data. Microblocks can be compressed by using compression algorithms. To speed up queries, this cache caches decompressed microblock data. user_row_cache Caches the hotspot rows in a table. bf_cache Caches the Bloom filters created for macroblocks whose spot query results are empty for a specified number of times. This improves the efficiency of filtering empty queries. fuse_row_cache Caches row snapshot data to speed up point queries and prevent cache failures caused by minor compactions or major compactions. opt_table_stat_cache Caches the statistics of a partition, such as the number of rows, number of macroblocks, and number of microblocks. opt_column_stat_cache Caches the statistics of a column in the partition, such as the number of null values, number of non-null values, maximum value, and minimum value. The following table describes the cache types of a user tenant.
Cache type Description index_block_cache Caches microblock indexes to speed up access to microblock data. user_block_cache Caches microblock data. Microblocks can be compressed by using compression algorithms. To speed up queries, this cache caches decompressed microblock data. user_row_cache Caches the hotspot rows in a table. bf_cache Caches the Bloom filters created for macroblocks whose spot query results are empty for a specified number of times. This improves the efficiency of filtering empty queries. fuse_row_cache Caches row snapshot data to speed up point queries and prevent cache failures caused by minor compactions or major compactions. tmp_block_cache Serves as the write buffer and write cache to cache temporary files. tmp_page_cache Serves as the read cache to cache temporary files. opt_table_stat_cache Caches the statistics of a partition, such as the number of rows, number of macroblocks, and number of microblocks. opt_column_stat_cache Caches the statistics of a column in the partition, such as the number of null values, number of non-null values, maximum value, and minimum value.