@Rocky docs.starrocks.io/docs/…/resource_group#… Given documentation about exclusive cpu cores and percent, I assume using this resource group config means hard isolation. But the issue I have is a user is sporadic. On certain times it hogs 100% of CPU and no one else can query. But I want a situation where the user is prevented from using more than a set amount of cpu cores but other users can borrow these cores when they are idle.

Your observation that

exclusive_cpu_cores

(or

exclusive_cpu_percent

) provides "hard isolation" is correct, but the behavior regarding borrowing actually supports exactly the situation you are looking for. In StarRocks (from v3.3.5 for cores, and v4.1 for percentages), CPU resources are categorized into Exclusive and Shared pools: 1. The "Hog" User (Exclusive Resource Group) By placing the sporadic user in a resource group with

exclusive_cpu_cores

(or

exclusive_cpu_percent

), you achieve the first part of your goal: * Hard Cap (Quota): This user is strictly limited to the allocated cores. Even if the rest of the cluster is idle, this user cannot use more than their set amount. This prevents them from hogging 100% of the CPU. * Isolation: This group runs in its own dedicated thread pool, bound to specific CPU cores. 2. Other Users (Shared Resource Groups) Other users should be in resource groups using

cpu_weight

(Shared groups). These groups run on the "Shared" pool of cores (any cores not reserved by Exclusive groups). 3. The "Borrowing" Behavior StarRocks allows Shared groups to borrow from Exclusive groups, but not the other way around. * Borrowing (Idle Cores): By default, the BE configuration

enable_resource_group_cpu_borrowing

is set to

true

. This means when your "hog" user is idle, the Shared groups (everyone else) can borrow those reserved cores. * No Borrowing by the Hog: The Exclusive group (the hog) is not allowed to borrow from the Shared pool. They are forever capped at their

exclusive_cpu_cores

setting. Summary of Configuration To achieve your goal (limit the hog, allow others to borrow): 1. Configure the "Hog" Resource Group:

sql
    CREATE RESOURCE GROUP hog_user_group WITH (
        "exclusive_cpu_cores" = "8", -- Set your desired limit here
        "mem_limit" = "20%"
    );

2. Configure Other Resource Groups: Ensure other users/groups use

cpu_weight

instead of

exclusive_cpu_cores

.

sql
    CREATE RESOURCE GROUP regular_user_group WITH (
        "cpu_weight" = "10",
        "mem_limit" = "50%"
    );

3. Verify Borrowing is Enabled (Default is true): You can check or set this dynamically:

sql
    UPDATE information_schema.be_configs
    SET VALUE = "true"
    WHERE NAME = "enable_resource_group_cpu_borrowing";

Note on Versioning: *

exclusive_cpu_cores

was introduced in v3.3.5. *

exclusive_cpu_percent

was introduced in v4.1. * The sum of

exclusive_cpu_cores

across all groups must be less than the total cores on the BE (specifically

min_be_cpu_cores - 1

) to ensure at least one core remains for the Shared pool. References • administration/management/monitoring/metrics.md • administration/management/resource_management/resource_group.md • best_practices/audit_log_resource_group.md • faq/resource_isolation_faq.md

@Rocky But the documentation specifically says

• Exclusive: Reserves a specified number of CPU cores exclusively for this resource group, making them unavailable to other groups, even when idle.

The documentation you quoted describes the default hardware-level behavior of an Exclusive Resource Group, but StarRocks provides a specific configuration to allow the "borrowing" you want. To achieve your goal—preventing the "hog" user from exceeding a cap while allowing others to use those cores when idle—you should use the following setup: 1. The Configuration * The "Hog" User: Place them in a resource group using

exclusive_cpu_cores

(or

exclusive_cpu_percent

in v4.1+). This creates a Hard Limit. This user will be strictly capped and cannot borrow cores from the rest of the cluster, even if it is idle. * Other Users: Place them in resource groups using

cpu_weight

. These are Shared Resource Groups. * The Toggle: Ensure the BE configuration

enable_resource_group_cpu_borrowing

is set to

true

(it is true by default). 2. How it works with

enable_resource_group_cpu_borrowing

While the introductory bullet point in the docs says cores are "unavailable to others even when idle," the technical detail further down explains the override: * Borrowing Direction: Shared groups (those with

cpu_weight

) can borrow idle cores from Exclusive groups if this setting is true. * Hard Cap: The Exclusive group (the hog) cannot borrow from the Shared pool. They are always restricted to their set

exclusive_cpu_cores

. This perfectly matches your requirement: The sporadic user is prevented from hogging the whole machine, but their reserved capacity isn't wasted when they aren't using it. Why you might see 100% usage now If you are currently seeing the user hog 100% of the CPU, it is likely because: 1. They are in a Shared Group (

cpu_weight

): Shared groups are designed to expand to use all available CPU if no one else is competing. Even with a low weight, if they are the only ones active, they will take 100%. 2. You haven't set

exclusive_cpu_cores

yet: Without this specific parameter, StarRocks uses "soft isolation," which prioritizes utilization over strict limits. Summary of Actions 1. Create the Exclusive Group for the hog:

sql
    CREATE RESOURCE GROUP hog_group WITH (
        "exclusive_cpu_cores" = "10", -- Cap them at 10 cores
        "mem_limit" = "20%"
    );

2. Ensure others are in Shared Groups:

sql
    CREATE RESOURCE GROUP regular_group WITH (
        "cpu_weight" = "10",
        "mem_limit" = "50%"
    );

3. Confirm the borrowing setting (Optional):

sql
    -- This is true by default, but you can verify/set it:
    UPDATE information_schema.be_configs
    SET VALUE = "true"
    WHERE NAME = "enable_resource_group_cpu_borrowing";

Important Note: The total

exclusive_cpu_cores

across all groups must be at least one core less than the total cores on your BE (

min_be_cpu_cores - 1

) to ensure there is always a "Shared" pool for the other users to live in. References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • administration/management/monitoring/metrics.md • best_practices/audit_log_resource_group.md

@Rocky Is exclusive cores per machine or across entire cluster

The configuration is applied per machine (BE node), not as a total sum across the entire cluster. If you set

exclusive_cpu_cores = 8

, then every Backend (BE) node in your cluster will reserve exactly 8 of its local cores for that specific resource group. Key points about this per-node limit: * Uniform Enforcement: Because StarRocks distributes query execution tasks across all BEs, this ensures the "hog" user is capped consistently on every machine they touch. * The

min_be_cpu_cores

Rule: When setting this value, StarRocks checks the BE with the fewest cores in your cluster. You cannot set

exclusive_cpu_cores

to a value higher than

min_be_cpu_cores - 1

. This ensures that even your smallest machine has at least one core left over for the "Shared" pool. * Scaling: If you add more BE nodes to your cluster, the "hog" user's total aggregate CPU capacity across the cluster increases, but their impact on any single machine remains strictly capped at 8 cores. Summary of

exclusive_cpu_percent

(v4.1+) This follows the same logic: if you set it to

20%

, it means 20% of the cores on each individual BE are reserved for that group. How to verify on a specific node You can see how many cores are bound to a resource group's threads on a specific BE by querying the metadata:

sql
SELECT BE_ID, NAME, BOUND_CPUS 
FROM information_schema.be_threads 
WHERE NAME LIKE '%<your_resource_group_id>%';

This will show you exactly which cores are assigned to that group's execution threads on each BE. References • administration/management/resource_management/resource_group.md • best_practices/audit_log_resource_group.md • faq/resource_isolation_faq.md • administration/management/BE_configuration.md • administration/management/monitoring/metrics.md References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • administration/management/BE_configuration.md • best_practices/audit_log_resource_group.md