starrocks/starrocks-debug-skills/resource-isolation

Claude Code and agent skill by starrocks/starrocks-debug-skills

Trust tier 2
  • community
LLM review pending
Source check pending

Checking that the SKILL.md file is still in the repository.

Use when setting up or troubleshooting resource groups, query queues, or big-query circuit breakers — or when a runaway query is starving other workloads. Covers resource group classifier mismatches (queries falling to default_wg), CPU/memory/scan limit calibration from audit log percentiles, SQL blacklist patterns, query queue full rejection errors, and emergency statistics collection disable when BRPC is saturated.

Install

npx vskill@latest install starrocks/starrocks-debug-skills/resource-isolation

SKILL.md

Resource Isolation, Query Queue, and Query Governance

Investigation guide for resource groups, query queues, big-query circuit breakers, and SQL blacklisting.

Five root causes account for most resource isolation issues:

  • Cause A — Unclassified queries monopolize resources (fall into default_wg)
  • Cause B — Memory limit too tight causing disk spill and IO contention
  • Cause C — Queue full causing immediate rejection (misleading error to client)
  • Cause D — Big query unbounded for a specific user (no big_query_* limits set)
  • Cause E — Statistics collection saturating BRPC worker threads

Metric Taxonomy — Read This First

Before diagnosing, understand the observable signals for resource isolation issues.

FE metrics
MetricMeaning
starrocks_fe_query_resource_groupQuery count per resource group — which groups are being used
starrocks_fe_query_resource_group_latencyPercentile latencies per group — which groups have high P99
starrocks_fe_query_resource_group_errError count per group — which groups are rejecting queries

How to retrieve:

bash
# All resource group metrics from FE
curl -s "http://<fe_host>:8030/metrics?type=json" \
| python3 -m json.tool \
| grep -A 5 "resource_group"
# Or raw metrics
curl -s "http://<fe_host>:8030/metrics" | grep resource_group
BE metrics
MetricMeaning
starrocks_be_resource_group_cpu_limit_ratioCPU allocation ratio per group per BE node
starrocks_be_resource_group_mem_limit_bytesMemory limit in bytes per group per BE node

How to retrieve:

bash
# BE resource group metrics
curl -s "http://<be_host>:8040/metrics" | grep resource_group
# Loop across all BEs
for be in <be1> <be2> <be3>; do
echo "=== $be ==="
curl -s "http://$be:8040/metrics" | grep resource_group
done
Query queue metrics
Metric / ObservableMeaning
query_queue_mem_used_pct_limitMemory usage threshold that triggers queuing
Queue depth in FE metricsHow many queries are currently waiting
FE log query rejected: queue is fullQueue at capacity — new queries rejected immediately

How to retrieve:

bash
# Check queue configuration
mysql -e "ADMIN SHOW FRONTEND CONFIG LIKE 'query_queue%';"
# Check queue depth in FE metrics
curl -s "http://<fe_host>:8030/metrics" | grep query_queue
# Check if queries are being queued or rejected
grep -E "queue is full|admitted to queue|query rejected" fe/log/fe.log | tail -20
Audit log signals
FieldMeaning
resource_groupWhich resource group the query was classified into
cpuCostNsTotal CPU cost in nanoseconds — use for cpu_core_limit tuning
memCostBytesPeak memory — use for big_query_mem_limit tuning
scanRowsRows scanned — use for big_query_scan_rows_limit tuning

How to retrieve:

bash
# Queries assigned to default_wg (unclassified)
grep "resource_group=default_wg" fe/log/fe.audit.log | wc -l
# CPU cost per user (for cpu_core_limit tuning)
awk -F'|' '{
for(i=1;i<=NF;i++) {
if($i ~ /^User=/) user=substr($i,6)
if($i ~ /^cpuCostNs=/) cpu=substr($i,12)+0
}
print user, cpu
}' fe/log/fe.audit.log | awk '{a[$1]+=$2} END{for(u in a) print a[u]/1e9, u}' | sort -rn | head -10
# Memory outliers
grep "memCostBytes" fe/log/fe.audit.log \
| awk -F'memCostBytes=' '{print $2}' | cut -d'|' -f1 | sort -rn | head -10

Key rules for interpretation:

  1. CPU limit in resource groups is soft (proportional sharing when contended); memory limit is hard (query fails immediately when exceeded). Tune memory limits conservatively to avoid false kills.
  2. Queries classified into default_wg have no effective CPU or memory limits — default_wg cannot be altered. If queries fall here, add a classifier.
  3. starrocks_fe_query_resource_group_err counts both hard memory kills and queue rejections — drill into FE log to distinguish.
  4. Resource group settings are per-BE — mem_limit = 30% means 30% of each individual BE's memory, not 30% of the cluster total.

Resource Isolation Issue Reference

SymptomRoot causeQuick confirm
Queries fall into default_wg; no resource classificationNo classifier matches the query`grep "resource_group=default_wg" fe.audit.log \wc -l`
Memory limit exceeded error but CPU is finemem_limit too tight for operator peakCheck memCostBytes P99 in audit vs mem_limit setting
Queries rejected immediately (not after timeout)Queue full — max_queued_queries reached`grep "queue is full" fe.log \tail -5`
Big query runs for hours; no circuit breaker firesNo big_query_* limits on resource groupSHOW RESOURCE GROUPS — check big_query_* fields
All queries slow; BRPC thread pool saturatedStatistics collection flooding BRPCgrep "rpc.*stat" fe.log — check case-002 pattern
Small queries starve during large analytical queryUnclassified large query in default_wgSHOW PROC '/current_queries' — look for no resource_group
Spilling query causes collateral IO slowdownmem_limit too low; disk spill on shared driveBE disk await time high; spill dir same as data dir

Phase 1 — Identify the Issue

Step 1.1 — Check query classification
sql
-- Are queries being classified into resource groups?
-- Check a running query's resource group:
EXPLAIN VERBOSE <SQL>;
-- Look for: ResourceGroup: <group_name>
-- Set resource group for current session (for testing):
SET resource_group = '<group_name>';
bash
# What fraction of queries go to default_wg (unclassified)?
grep "resource_group=default_wg" fe/log/fe.audit.log | wc -l
grep "resource_group=" fe/log/fe.audit.log | wc -l
# High ratio → Cause A
Step 1.2 — Check for memory limit kills and queue rejections
bash
# Memory limit exceeded errors
grep -E "Memory limit exceeded|MemTracker exceed" be/log/be.log | tail -10
# → Cause B
# Queue full rejections
grep -E "queue is full|query rejected" fe/log/fe.log | tail -10
# → Cause C
# Unbounded big queries (no circuit breaker fired)
grep "$(date +'%Y-%m-%d')" fe/log/fe.audit.log \
| awk -F'QueryTime=' 'NF>1{qt=$2+0; if(qt>600000) print}' | tail -10
# QueryTime > 600s → Cause D
Step 1.3 — Check statistics collection saturation
bash
# Statistics-related BRPC errors
grep -E "rpc.*statistic|statistic.*rpc|brpc.*fail" fe/log/fe.log | tail -10
# → Cause E

Issue signal → Cause mapping:

PatternPoints toward
High default_wg query ratioCause A — unclassified queries
Memory limit exceeded on specific resource groupCause B — mem_limit too tight
queue is full in FE log; immediate client rejectionCause C — queue full
Queries from one user running for hours; no killCause D — unbounded big query
BRPC failures correlated with statistics collection scheduleCause E — stats collection saturation

Phase 2 — Measure Current State

Step 2.1 — List all resource groups and their configuration
sql
SHOW RESOURCE GROUPS ALL;
-- Key fields: cpu_core_limit, mem_limit, concurrency_limit
-- big_query_cpu_second_limit, big_query_scan_rows_limit, big_query_mem_limit
Step 2.2 — Measure actual resource usage from audit log
sql
-- CPU usage per user (last 30 days) — for cpu_core_limit tuning
SELECT user, SUM(cpuCostNs)/1e9 AS cpu_sec
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK')
AND timestamp >= now() - INTERVAL 30 DAY
GROUP BY user
ORDER BY cpu_sec DESC;
-- Memory P99 per user — for big_query_mem_limit tuning
SELECT user, percentile_approx(memCostBytes, 0.99) AS mem_p99
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK')
GROUP BY user
ORDER BY mem_p99 DESC;
-- Query time P99 per user — for big_query_cpu_second_limit tuning
SELECT user, percentile_approx(queryTime, 0.99)/1000 AS time_p99_sec
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK')
GROUP BY user
ORDER BY time_p99_sec DESC;

Phase 3 — Take Action by Cause

Cause A — Unclassified Queries Monopolize Resources

Confirm all match:

  • High fraction of queries in fe.audit.log show resource_group=default_wg
  • SHOW PROC '/current_queries' shows queries with no resource group or default_wg
  • Small queries starve when large queries run

Mechanism: Queries that match no classifier are assigned to default_wg, which has no configurable CPU or memory limits. A single large analytical query in default_wg consumes all available BE CPU and memory, starving smaller concurrent queries. default_wg cannot be modified — the fix is to create classifiers that capture all query patterns.

Actions:

sql
-- Step A-1: Create resource groups for each user type
CREATE RESOURCE GROUP rg_bi
TO (user='bi_user', role='bi_role')
PROPERTIES (
"cpu_core_limit" = "10",
"mem_limit" = "30%",
"concurrency_limit" = "10",
"big_query_cpu_second_limit" = "600",
"big_query_scan_rows_limit" = "1000000000",
"big_query_mem_limit" = "10737418240"
);
CREATE RESOURCE GROUP rg_etl
TO (user='etl_user')
PROPERTIES (
"cpu_core_limit" = "16",
"mem_limit" = "40%",
"concurrency_limit" = "5"
);
-- Step A-2: Create a catch-all group to prevent default_wg fallback
CREATE RESOURCE GROUP rg_default_catch
TO () -- matches all unmatched queries
PROPERTIES (
"cpu_core_limit" = "4",
"mem_limit" = "20%",
"concurrency_limit" = "20"
);
-- Step A-3: Verify classification is working
-- Run a query and check EXPLAIN VERBOSE for ResourceGroup field
EXPLAIN VERBOSE SELECT COUNT(*) FROM <table>;

→ Go to Phase 4: Verify Recovery


Cause B — Memory Limit Too Tight Causing Disk Spill

Confirm all match:

  • BE log shows query spill to disk or MemTracker exceed limit
  • Disk await time high on BE hosts during affected queries
  • Spill directory is on the same disk as data storage

Mechanism: Resource group memory limits are hard limits — when a query's operator (sort buffer, hash table) exceeds the group's mem_limit, it spills intermediate data to disk. If the spill directory shares a disk with tablet data storage, compaction, and scan operations, IO contention degrades all queries on that BE. Multiple concurrent spilling queries compound the effect.

Actions:

bash
# Step B-1: Identify current mem_limit vs actual P99 usage
# (Use audit log query from Phase 2 Step 2.2)
# Step B-2: Configure dedicated spill directory on separate disk
# In be.conf:
# spill_local_storage_dir = /data/spill/starrocks
mkdir -p /data/spill/starrocks
echo "spill_local_storage_dir = /data/spill/starrocks" >> be/conf/be.conf
# Requires BE restart
sql
-- Step B-3: Increase mem_limit based on P99 usage (set to 1.5x P99)
ALTER RESOURCE GROUP rg_bi SET PROPERTIES (
"mem_limit" = "45%"
);
-- Step B-4: Set big_query_mem_limit as circuit breaker (2x P99)
ALTER RESOURCE GROUP rg_bi SET PROPERTIES (
"big_query_mem_limit" = "21474836480" -- 20GB
);

→ Go to Phase 4: Verify Recovery


Cause C — Queue Full Causing Immediate Rejection

Confirm all match:

  • FE log shows query rejected: queue is full
  • Client receives immediate connection error (not after a wait timeout)
  • query_queue_max_queued_queries is reached during burst traffic

Mechanism: When a resource group reaches concurrency_limit, subsequent queries enter the queue. When query_queue_max_queued_queries is reached, additional queries are rejected immediately with an error — not after a timeout. Clients without retry logic interpret this as a cluster crash rather than resource exhaustion. The error message may appear as a generic connection error at the application layer.

Actions:

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 100 of 100Pattern checks on the skill's files.
  • Model reviewNot runA model review is scheduled for the next rescan.

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

7-day trend score
0

Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/starrocks/starrocks-debug-skills/resource-isolation/badge)](https://verified-skill.com/skills/starrocks/starrocks-debug-skills/resource-isolation)

Something wrong with this skill or its page? Tell us.