@Rocky I have version 4.0.10-5b36164 and I dont see mem_pool column in resource groups

The

mem_pool

attribute for resource groups was introduced in StarRocks v4.0 (specifically v4.0.2). Since you are on version

4.0.10-5b36164

, your cluster does support this feature. The reason you might not see the

mem_pool

column is that it is often excluded from the default output of the management commands. To see it, you must use the

VERBOSE

keyword:

sql
SHOW VERBOSE RESOURCE GROUPS ALL;

Key details about

mem_pool

in v4.0: * Purpose: It allows multiple resource groups to share a common memory pool and enforce a collective memory limit. * Default Behavior: If you do not specify a

mem_pool

when creating or altering a group, it defaults to

default_mem_pool

. * Visibility: In v4.0, extended attributes like

mem_pool

(and deprecated ones like

type

) are only displayed when running the

SHOW VERBOSE

variation of the command. If you are checking via

information_schema.resource_groups

and it is still missing, it is recommended to use the

SHOW VERBOSE

command as the primary source of truth for resource group metadata in this version. References • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUP.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_USAGE_RESOURCE_GROUPS.md • sql-reference/System_variable.md • administration/management/resource_management/resource_group.md

@Rocky If I wanna isolate some user the best way can be to for instance create shared_pool assign all the other groups on that pool and give them mem_limit 70% and on that user group assigna another pool and give 90% this difference 20% will be only available for that user and also give it exclusive cpu

Your proposed strategy is a solid way to achieve isolation in StarRocks v4.0+, though there are a few technical requirements to keep in mind regarding how

mem_pool

and

exclusive_cpu_cores

behave. 1. Memory Isolation with

mem_pool

Your plan to use separate pools for the "isolated" user vs. "everyone else" is correct. Here is how the logic works in StarRocks: * Identical Limits Requirement: All resource groups assigned to the same

mem_pool

must have the same

mem_limit

value. * The "Shared" Pool: If you put all other users into

pool_others

with a

mem_limit

of

70%

, they will collectively compete for that 70% slice of memory. * The "Isolated" User: By putting your specific user in a different pool (e.g.,

pool_special

) with a

mem_limit

of

90%

, that user is not restricted by the 70% cap of the others. Note on your "20% difference" logic: In StarRocks,

mem_limit

is a hard limit, not a reservation. * If the "others" hit 70%, they will start spilling to disk or fail. * The "special" user can use up to 90% of the BE memory regardless of what the others are doing. _ Because the total (

70% + 90%

) exceeds 100%, if _both* groups try to use their full limit simultaneously, the BE process itself might hit its global memory limit (usually 90% of physical RAM), and the system will trigger its own safeguards (killing queries or GC). 2. CPU Isolation with

exclusive_cpu_cores

This is the strongest form of isolation available. * Reservation: Setting

exclusive_cpu_cores

reserves those cores specifically for that group. Other groups (using

cpu_weight

) cannot use these cores even if the "special" user is idle (unless you have

enable_resource_group_cpu_borrowing

set to

true

). * Quota: The "special" user is also strictly limited to only those cores and cannot burst into the shared pool used by other users. Recommended Configuration To implement your plan, the SQL would look like this:

sql
-- 1. Create the pool for 'other' users
CREATE RESOURCE GROUP rg_others
TO (user='user_a', user='user_b')
WITH (
    'mem_limit' = '70%',
    'mem_pool' = 'pool_others',
    'cpu_weight' = '10' -- These users share the remaining CPU
);

-- 2. Create the isolated group for the 'special' user
CREATE RESOURCE GROUP rg_special
TO (user='special_user')
WITH (
    'mem_limit' = '90%',
    'mem_pool' = 'pool_special',
    'exclusive_cpu_cores' = '8' -- Reserves 8 physical cores exclusively
);

Important constraints: 1. CPU Limit: The total

exclusive_cpu_cores

across all groups must be less than the total cores on your smallest BE minus one (i.e., you must leave at least 1 core for the "Shared" pool). 2. Either/Or: A resource group can have either

cpu_weight

(shared) or

exclusive_cpu_cores

(exclusive), but not both. This setup effectively ensures your "special" user has its own dedicated lane for CPU and a much larger, independent bucket for memory. References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • administration/management/monitoring/metrics.md

@Rocky no for instance if I will give shared to 70% and for special 80% and system query queue has also 85% this 10% can be exclusively used for special resource group? but there is a pain ram can be used by cache as well so it already can be allocated by 30% and on top of it when resource group can run total ram*70% this cache + shared pool can allocate more than 70% together and there is no much space for even special pool no?

Your reasoning about the "10% difference" is correct in terms of a hard ceiling, but there are some nuances regarding how StarRocks manages memory globally and how caches interact with these limits. 1. The "Exclusive 10%" Logic If you set

rg_shared

to 70% and

rg_special

to 80%: * The 10% is exclusive as a ceiling:

rg_shared

is strictly forbidden from using more than 70% of the BE's memory limit. This effectively "leaves" the range between 70% and 80% available only for

rg_special

(and system overhead). * It is NOT a reservation: If

rg_special

is idle, that 10% is not sitting empty; it can be used by the system for Page Cache or metadata. However, the moment

rg_special

needs it, it can claim it (potentially triggering cache eviction), whereas

rg_shared

never can. 2. The Cache vs. Query Pool Problem You are right to worry about the overlap. Here is the memory hierarchy in a StarRocks BE: 1. Physical RAM: (e.g., 100GB) 2. BE Global Limit: Usually 90% of RAM (90GB). This is the "100%" that Resource Groups refer to. 3. The Shared Pool: Inside that 90GB, StarRocks manages: * Caches: Page Cache, Metadata Cache, etc. * Query Memory: Managed by your Resource Groups. * Overhead: Compaction, Memtables, etc. The "Pain Point" you identified: If

rg_shared

is set to 70% and actually uses all 70%, and your Caches are taking 30%, you have hit 100% of the BE's memory limit. At this point: * StarRocks will try to evict Caches: It will prioritize query execution and try to shrink the Page Cache to make room for

rg_special

. * OOM Risk: If the caches cannot be shrunk further (or if the memory is held by non-evictable items like Memtables), and

rg_special

tries to use its extra 10%, the BE will trigger its global memory protection. This may result in killing the largest memory-consuming query across any group to save the BE process. 3. Better Isolation Strategy To prevent the "Cache + Shared Pool" from choking out your special user, consider these two settings: * `spill_mem_limit_threshold`: Set this on your

rg_shared

group (e.g., to

0.8

). This forces the "shared" users to start spilling to disk once they hit 80% of their 70% limit (i.e., 56% of total memory). This creates a "soft buffer" that prevents them from slamming into the hard limit and competing with your special user for the last bits of RAM.

sql
    ALTER RESOURCE GROUP rg_shared WITH ('spill_mem_limit_threshold' = '0.8');

* Don't Oversubscribe 100%: If you want true stability, the sum of your hard

mem_limit

values plus your expected cache size should ideally stay near 100% of the BE limit. If you give

rg_special

80%, you are essentially saying "In the worst case, this group can take almost the entire machine." Summary for your plan: The "10% difference" works as a hard barrier for the shared users. However, because caches share the same global BE bucket, your

rg_special

is still vulnerable to global BE memory pressure. To protect it, lower the

mem_limit

of the other groups or use spilling to ensure they don't exhaust the global pool before the special user gets a chance to run. References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • administration/management/resource_management/Memory_management.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md

@Rocky I use spill = force so whenever possible it always spill

Using

spill_mode = 'force'

is a very effective way to "harden" your isolation strategy, but you are correct to be concerned about the interaction with the Page Cache. Here is how your strategy plays out with forced spilling and the memory/cache trade-off: 1. Does

spill = force

help with isolation? Yes, significantly. By forcing queries to spill, you are essentially telling StarRocks: "Do not use RAM for intermediate data (sorts, joins, aggregates) if you can use a disk instead." * For the 70% group (

rg_shared

): This ensures they never "burst" or spike in memory usage unexpectedly. They will stay within a very lean memory footprint, making the 70% limit a very safe ceiling. * For the 80/90% group (

rg_special

): They will have "first-class" access to the remaining RAM. 2. The Cache Conflict (Page Cache vs. Resource Groups) You correctly identified the "pain point": The Page Cache is managed globally, not by Resource Groups. If your BE has 100GB of RAM and the BE global limit is 90GB: * The Problem: If your Page Cache grows to 30GB (30%) and your

rg_shared

queries (70% limit) are using 60GB, you have reached 90GB. If your

rg_special

user then tries to run a query, the BE is already at its global limit. * The Result: StarRocks will attempt to evict the Page Cache to make room for the new query. However, cache eviction is not instantaneous. If the memory pressure is too high, the BE might kill a query (OOM) before the cache can be cleared. 3. How to solve the Cache vs. Group overlap To ensure that "special" 10-20% of RAM is actually available for your isolated user and not swallowed by the cache, you should cap the Page Cache in your `be.conf`: 1. Limit the Page Cache: By default, the Page Cache can grow quite large. You can explicitly limit it so it doesn't "eat" into the space you want to reserve for your special resource group.

properties
    # example: limit page cache to 20% of total RAM
    storage_page_cache_limit = 20%

2. Use `spill_mem_limit_threshold`: Even with

spill_mode = 'force'

, you should set the resource group property

spill_mem_limit_threshold

to a lower value (e.g.,

0.5

) for your shared group. This ensures they start offloading even earlier, keeping the global memory pressure low. Summary of your "10% Exclusive" Plan With

spill = force

, your plan to create a gap (70% vs 80%) works like this: * The 70% group is "pushed" to the disk very early, leaving more "physical" RAM idle. * The 80% group can use that idle RAM. * The "Exclusive" 10% is effectively a buffer. Because the shared group is capped at 70%, that 10% is "invisible" to them. It can only be used by the Special group or the Page Cache. * Recommendation: If you limit your Page Cache to ~20% and keep your shared groups at ~60-70%, you create a "guaranteed" window of physical RAM where your special user can operate without fighting the cache or other users. One warning:

spill = force

does not cover everything. It does not limit memory used by metadata, memtables (for loading data), or complex expression evaluations. Therefore, always leave at least 5-10% "unallocated" (e.g., don't let the sum of all limits exceed 90-95%) for system stability. References • administration/management/resource_management/resource_group.md • administration/management/resource_management/spill_to_disk.md • administration/management/BE_configuration.md • faq/resource_isolation_faq.md • administration/management/resource_management/Memory_management.md