Overview
Within Resource Management, there are three main areas of usage that take place while the database is online: For configuration that must be performed while the database is offline, see Resource Management Configuration.Tiered Storage
Once the database has started, only a limited set of configuration parameters are able to be modified for any tier:- capacity - the maximum capacity of the tier
- high_watermark - the high watermark, as a percentage, to use for watermark-based eviction
- low_watermark - the low watermark, as a percentage, to use for watermark-based eviction
The capacity of the VRAM Tier cannot be changed at runtime.
Altering a Tier
To modify a tier, use the /alter/tier endpoint. For example, in Python, to resize a Disk Cache Tier instance with ID disk2 to 500MB and set the high & low watermark percentages to 95% & 90%, respectively:Viewing a Tier
To view all tier layouts & attributes, use the /show/resource/statistics endpoint. For example, in Python, to show the per-rank statistics of all tiers:Viewing a Table’s Tier Distribution
To view a table’s per-rank tier distribution, use the table_names option of the /show/resource/statistics endpoint, specifying the name of the table as the value. For example, in Python, to show the per-rank tier distribution of the preferred_customer table:Resource Groups
Any resource groups can be created via the API or GAdmin while the database is running. The following resource groups will exist in every Kinetica instance:- system: used by the database for scheduling its own resources; cannot be modified
- default: default resource group; can be modified when the database is stopped and will take effect when the database is subsequently started
Managing Resource Groups
To create a resource group, use the /create/resourcegroup endpoint. For example, in Python, to create a system administrator resource group named memory_over_execution, which favors memory usage over execution speed & priority, using the following criteria:- 10GB of allowed VRAM usage
- 100GB of allowed RAM usage
- Maximum servicing worker thread count of 5
- Maximum scheduling priority of 30
- Increasing the VRAM allowance to 20GB
- Increasing the RAM allowance to 200GB
- Increasing the maximum allowable scheduling priority to 40
- Setting the maximum eviction priority group members are allowed to assign objects to 4
Assigning Resource Groups to Users
To assign a resource group to a user, upon creation, use the /create/user/internal endpoint. For example, in Python, to create a user named jsmith and assign the resource group named memory_over_execution:Assigning Resource Groups to Roles
To assign a resource group to a role, upon creation, use the /create/role endpoint. For example, in Python, to create a role named executive and assign the resource group named execution_over_memory:Tier Strategies
To assign a tier strategy to a table upon creation, use the /create/table endpoint. For example, in Python, to create a table named preferred_customer and assign a tier strategy with the default VRAM Tier and below-average RAM Tier eviction priorities:- For id & name column data associated with customers seen in the last minute, cache those column in VRAM and make them unevictable from the RAM Tier
- For all other data associated with customers seen in the last three days, give the data the highest evictable priority within the RAM Tier
- For all remaining data, decrease the eviction priority within the RAM Tier slightly, while adding an above-average priority backing cache on the Disk Cache Tier instance named disk2