RonJay
07/16/2026, 8:32 AMRocky
07/16/2026, 8:33 AMsql
SET enable_spill = true;
SET spill_mode = 'auto'; -- 'auto' triggers based on thresholds; 'force' spills regardless of memory usage.
1. Resource Group Thresholds
If you use Resource Groups for isolation, you can define a specific threshold for that group:
* spill_mem_limit_threshold:
* Description: The percentage of the resource group's memory limit that, when reached, triggers spilling for queries in that group.
* Range: (0, 1]. Default is 1.0.
* Usage:
sql
CREATE RESOURCE GROUP my_rg WITH (
'mem_limit' = '50%',
'spill_mem_limit_threshold' = '0.8'
);
2. BE Configuration (Global/System Level)
These are set in your be.conf and usually require a restart:
* query_pool_spill_mem_limit_threshold:
* Triggers spilling when the total memory usage of all queries exceeds a percentage of the total query pool memory limit.
* Default: 1.0 (100%). Introduced in v3.2.7.
* default_mv_resource_group_spill_mem_limit_threshold:
* Specifically for Materialized View refresh tasks in the default resource group.
* Default: 0.8 (80%). Introduced in v3.1.
3. Query & Operator Level (Session Variables)
* Per-Query 80% Rule: By default, even if Resource Groups are disabled, StarRocks triggers spilling when a single query's memory usage exceeds 80% of its query_mem_limit.
* spill_revocable_max_bytes:
* Description: An experimental threshold (in bytes) for individual operators (like Sort or Aggregate). If an operator's "revocable memory" exceeds this value, it will initiate a spill.
* Default: 0 (disabled).
4. Disk Configuration
Note that spilling will not work unless a storage path is defined in `be.conf`:
* spill_local_storage_dir: Specifies the local directory for spill files.
* Example: spill_local_storage_dir=/data1/spill;/data2/spill
Summary Table
Level | Parameter | Default
Resource Group | spill_mem_limit_threshold | 1.0
BE (Global) | query_pool_spill_mem_limit_threshold | 1.0
BE (MV) | default_mv_resource_group_spill_mem_limit_threshold | 0.8
Session (Exp) | spill_revocable_max_bytes | 0
Session | query_mem_limit | (Spills at 80% of this value)
References
• administration/management/BE_configuration.md
• sql-reference/System_variable.md
• administration/management/FE_configuration.md
• administration/management/resource_management/resource_group.md
• administration/management/resource_management/spill_to_disk.mdRonJay
07/19/2026, 1:03 AMRocky
07/19/2026, 1:04 AMSET pipeline_dop = 8; (또는 CN 코어 수의 절반 정도)와 같이 *고정 값*으로 설정한 후 CPU 사용량과 쿼리 성능이 개선되는지 확인해 보세요. 10개 정도의 쿼리는 고정 값을 사용하는 것이 더 유리할 수 있습니다.
2. 데이터 분포 및 태블릿(Tablet) 수 확인
병렬도는 물리적으로 데이터를 담고 있는 태블릿 수에 비례합니다.
* 문제: 만약 조회하려는 데이터의 태블릿 수가 CN 개수에 비해 너무 적으면, 아무리 `pipeline_dop`을 높여도 특정 CN이나 코어만 일하고 나머지는 놀게 됩니다.
* 확인: `SHOW TABLET FROM table_name;`으로 태블릿 분포를 확인하거나, *Query Profile*에서 `ScanNode`가 실제로 몇 개의 태블릿을 처리했는지 확인하세요.
3. 리소스 그룹(Resource Group) 설정 확인
리소스 그룹을 사용 중이라면 `max_cpu_cores`가 설정되어 있는지 확인하세요.
* CN의 실제 CPU 코어는 많더라도, 리소스 그룹 설정에서 사용 가능한 코어 수를 제한(max_cpu_cores)해 두었다면 CPU 사용량이 낮게 유지될 수 있습니다.
* SHOW USAGE RESOURCE GROUPS; 명령어로 현재 리소스 그룹의 CPU 점유율을 확인해 보세요.
4. Query Profile을 통한 병목 지점 분석
가장 확실한 방법은 실행된 쿼리의 *Profile*을 보는 것입니다.
* WallTime vs CPU Time: Profile에서 실제 실행 시간(WallTime)은 긴데 CPU Time이 짧다면, CPU 연산이 아니라 *I/O(S3/HDFS에서 데이터 읽기)*나 *네트워크 전송*에서 대기가 발생하고 있는 것입니다.
* DOP 확인: Profile의 Pipeline 섹션에서 `DegreeOfParallelism`이 실제로 얼마로 할당되어 동작했는지 확인하세요. 만약 auto 로직에 의해 1이나 2로 잡혔다면 pipeline_dop 수동 조정이 필요합니다.
5. I/O 병목 (Lakehouse 아키텍처인 경우)
CN Pod를 사용 중이시라면 Shared-data(Storage-Compute separation) 구조일 가능성이 높습니다.
* 데이터를 외부 스토리지(S3 등)에서 가져오는 속도가 느리면 CPU는 데이터를 기다리느라(I/O Wait) 일을 하지 못합니다.
* 이 경우 `pipeline_dop`을 높여도 효과가 적으며, 데이터 캐시(Data Cache)가 활성화되어 있는지, 캐시 히트율이 높은지 확인해야 합니다.
요약 및 추천
1. 테스트: 특정 세션에서 SET pipeline_dop = <코어수의 절반>; 설정 후 10개 쿼리를 다시 돌려보세요. CPU 사용량이 올라가고 성능이 좋아진다면 auto 로직이 너무 보수적으로 작동한 것입니다.
2. 프로파일 확인: `ANALYZE PROFILE FOR 'query_id';`를 통해 실제 병렬도(DOP)와 I/O 대기 시간을 확인하는 것이 가장 우선입니다.
입니다.
3. 동시성 전략: StarRocks는 아주 높은 동시성(100 QPS 이상)에서는 `pipeline_dop=1`을 권장하지만, 10개 정도의 동시 쿼리에서는 적절한 병렬도(4~16)를 유지하는 것이 성능상 좋습니다.
References
• sql-reference/System_variable.md
• administration/management/resource_management/query_queues.md
• best_practices/query_tuning/query_planning.md
• faq/Sql_faq.md
References
• faq/Others.md
• faq/Sql_faq.md
• deployment/environment_configurations.md
• administration/management/resource_management/query_queues.md
• knowledge/usage/load/shared_data_batch_ingestion.md
• best_practices/audit_log_resource_group.mdRonJay
07/19/2026, 2:04 AMRocky
07/19/2026, 2:04 AMPending 상태로 머물고, root 사용자가 _statistics_ 데이터베이스에서 DELETE 쿼리를 수행 중이라면, 이는 *FE(Frontend)의 통계 정보(Statistics) 관리 로직이 메타데이터 락(Lock)을 점유하여 쿼리 플래닝(Planning) 단계를 막고 있기 때문*일 가능성이 매우 높습니다.
1. 원인 분석
StarRocks의 CBO(Cost-Based Optimizer)는 쿼리 실행 계획을 세울 때 _statistics_ DB의 통계 데이터를 참조합니다.
* 통계 정보 정리 작업: StarRocks는 주기적으로 오래된 통계 정보를 삭제(DELETE FROM _statistics_...)하는 백업/정리 작업을 수행합니다.
* 메타데이터 락 병목: 삭제해야 할 통계 데이터가 너무 많거나, _statistics_ DB의 테이블에 과부하가 걸리면 FE가 해당 DB에 *쓰기 락(Write Lock)*을 오래 유지하게 됩니다.
* 쿼리 플래닝 중단: 일반 사용자가 쿼리를 던지면 FE는 최적의 경로를 찾기 위해 통계 정보를 읽어야 하는데, 정리 작업의 쓰기 락 때문에 *읽기 락(Read Lock)*을 얻지 못하고 플래닝 단계에서 멈춥니다.
* 결과: 쿼리가 아직 CN으로 전달(Dispatch)되지 않았으므로 CN의 실행 쿼리 수는 0으로 표시되지만, FE 입장에서는 쿼리 처리가 시작되지 않아 대기 큐만 쌓이게 됩니다.
2. 해결 방법
1단계: 진행 중인 정리 작업 중단
우선 서비스 복구를 위해 해당 DELETE 쿼리를 강제 종료합니다.
sql
-- 실행 중인 프로세스 목록 확인
SHOW FULL PROCESSLIST;
-- root가 실행 중인 DELETE 쿼리의 Id를 찾아 KILL
KILL <Connection_Id>;
2단계: 통계 정보 자동 수집 및 정리 일시 비활성화
정리 작업이 다시 실행되어 문제를 일으키지 않도록 FE 설정을 임시로 조정합니다.
sql
-- 통계 정보 자동 수집 비활성화
SET GLOBAL enable_statistic_collect = false;
-- 통계 정보 자동 정리 주기 비활성화 (0 또는 매우 큰 값)
-- (FE config 파일이나 ADMIN SET CONFIG 명령으로 조정)
ADMIN SET FRONTEND CONFIG ("statistic_cleanup_interval_sec" = "0");
3단계: 통계 테이블 수동 최적화 (선택 사항)
만약 _statistics_ 내부 테이블에 데이터가 너무 많아 발생한 문제라면, 사용량이 적은 시간에 수동으로 해당 테이블을 정리하거나 ANALYZE 관련 설정을 튜닝해야 합니다. 특히 삭제된 테이블의 통계가 제대로 정리되지 않고 쌓였을 때 자주 발생합니다.
3. 상태 확인을 위한 명령어
* SHOW PROC '/backends';: BE/CN의 실제 부하 확인 (NumRunningQueries 확인).
* SHOW RUNNING QUERIES;: 현재 FE 큐에 쌓여 있는 쿼리들의 상태(State=PENDING) 확인.
* FE 로그 확인: `fe.log`에서 lock 혹은 waiting for lock 관련 경고 메시지가 있는지 확인하세요.
요약하자면, 현재 상황은 *FE 메타데이터 락 점유로 인한 병목*이며, CN의 문제가 아닙니다. root 유저의 통계 삭제 쿼리를 중단시키면 즉시 일반 쿼리들이 실행되기 시작할 것입니다.
References
• knowledge/trouble_shooting/fe_deadlock_problems.md
• using_starrocks/Cost_based_optimizer.md
• administration/management/resource_management/query_queues.md
• using_starrocks/running_queries.md
References
• knowledge/trouble_shooting/fe_deadlock_problems.md
• knowledge/usage/best-practice.mdRonJay
07/19/2026, 2:10 AMRocky
07/19/2026, 2:10 AMroot 사용자가 실행하는 DELETE FROM _statistics_... 또는 INSERT INTO _statistics_... 쿼리가 수천 초(Time) 이상 실행 중이라면 통계 정보 정리/수집 로직에 병목이 발생한 것입니다.
* 특히 `State`가 `Waiting for lock`이거나, 다른 일반 쿼리들이 Planning 단계에서 멈춰 있다면 확신할 수 있습니다.
2. _statistics_ 내부 테이블 크기 확인
통계 정보가 담기는 내부 테이블에 데이터가 비정상적으로 많으면 정리 작업(DELETE)이 느려지고 락을 오래 잡게 됩니다.
sql
-- 통계 테이블의 데이터 양 확인
SELECT count(*) FROM _statistics_.column_statistics;
SELECT count(*) FROM _statistics_.table_statistic_v1;
* 만약 로우(Row) 수가 수천만 건 이상이라면, 불필요하거나 오래된 통계 정보가 제때 삭제되지 않아 성능 저하를 일으키고 있는 것입니다.
3. `fe.log`에서 락(Lock) 및 통계 로그 확인
FE 로그(fe.log 또는 fe.warn.log)에서 다음과 같은 키워드를 검색하세요.
* DeadlockChecker: FE 내부에서 락 경합이 발생하면 로그에 찍힙니다. 락을 잡고 있는 스레드가 `StatisticExecutor`나 AnalyzeJob 관련인지 확인하세요.
* Statistic 관련 경고: Slow to collect statistics 혹은 통계 수집 중 발생한 Exception을 찾으세요.
* Waiting for the lock: 특정 DB(_statistics_)에 대한 락 대기 로그가 반복되는지 확인합니다.
4. SHOW ANALYZE STATUS 확인
현재 진행 중이거나 최근에 실패한 통계 수집 작업(ANALYZE)이 있는지 확인합니다.
sql
SHOW ANALYZE STATUS;
* `STATE`가 `RUNNING`인 작업이 너무 많거나, `FAILED`된 작업이 반복되고 있다면 FE에 과부하를 주고 있을 가능성이 큽니다.
5. FE 설정값 확인 (통계 정리 주기)
통계 정보 정리가 너무 자주 혹은 너무 드물게 일어나는지 설정을 확인합니다.
sql
-- FE 설정 확인 (Admin 권한 필요)
ADMIN SHOW FRONTEND CONFIG LIKE '%statistic%';
* `statistic_cleanup_interval_sec`: 통계 정리 주기 (기본값 24시간). 이 값이 너무 작으면 정리가 너무 자주 발생합니다.
* `enable_statistic_collect`: 통계 수집 활성화 여부.
요약: 문제가 확인되었다면?
만약 위 방법으로 통계 로직의 문제가 확인되었다면, 우선 실행 중인 DELETE 쿼리를 KILL 하여 서비스를 복구한 뒤, 다음 설정을 통해 자동 수집을 일시 중지하고 대용량으로 쌓인 통계 테이블을 정리해야 합니다.
sql
-- 자동 수집 비활성화
SET GLOBAL enable_statistic_collect = false;
References
• knowledge/trouble_shooting/fe_deadlock_problems.md
• using_starrocks/Cost_based_optimizer.md
• administration/management/FE_configuration.md
• sql-reference/sql-statements/data-manipulation/ANALYZE.md
• sql-reference/sql-statements/administration/ADMIN_SET_CONFIG.md
)
References
• knowledge/usage/best-practice.md
• administration/management/BE_configuration.mdRonJay
07/19/2026, 2:14 AMRocky
07/19/2026, 2:14 AMv3.1 이상에서 `enable_statistic_collect_on_first_load`까지 꺼져 있다면, 새로 만든 테이블에 데이터를 처음 로드할 때도 통계가 생성되지 않습니다. 이 경우 사용자가 수동으로 `ANALYZE TABLE`을 실행하기 전까지는 해당 테이블을 사용하는 모든 쿼리가 최적화되지 않은 상태로 실행됩니다.
4. 자원 활용 불균형
실행 계획이 꼬이면 특정 노드에 부하가 집중되거나, 불필요한 네트워크 I/O가 발생하여 클러스터 전체의 자원 효율이 떨어지게 됩니다.
──────────
권장 조치 사항
현재 발생한 _statistics_ 관련 락(Lock) 문제를 해결하기 위해 *임시로 끄는 것은 유효한 대응*이지만, 장기적으로는 다시 켜는 것이 좋습니다. 대신 다음과 같은 방식으로 튜닝하는 것을 권장합니다.
1. 임시 중단 후 수동 정리: 자동 수집을 끄고 root 유저의 DELETE 쿼리를 `KILL`한 뒤, _statistics_ DB의 테이블들이 너무 비대해졌는지 확인하고 수동으로 정리합니다.
2. 수집 범위 제한: 모든 컬럼을 수집하기보다 쿼리 조건(WHERE, JOIN, GROUP BY)에 자주 사용되는 주요 컬럼만 수집하도록 ANALYZE 설정을 조정할 수 있습니다.
3. 수집 주기 조정: statistic_cleanup_interval_sec 등을 조절하여 정리 작업이 너무 빈번하게 발생하지 않도록 설정합니다.
결론: 통계 수집을 끄면 *FE의 부하와 락 문제는 즉시 해결*되지만, *쿼리 실행 성능(특히 복잡한 조인)은 예측 불가능하게 느려질 수 있음*을 인지해야 합니다.
References
• using_starrocks/Cost_based_optimizer.md
• administration/management/FE_configuration.md
• faq/Sql_faq.md
References
• using_starrocks/Cost_based_optimizer.md
• administration/management/FE_configuration.md
• faq/Sql_faq.md
• sql-reference/sql-statements/data-manipulation/ANALYZE.md
References
• using_starrocks/Cost_based_optimizer.mdRonJay
07/19/2026, 2:16 AMRocky
07/19/2026, 2:16 AM_statistics_ 데이터베이스 내 테이블이 비대해졌는지 확인하는 가장 빠르고 정확한 방법은 *시스템 명령어*와 *직접 쿼리*를 병행하는 것입니다.
1. SHOW DATA 명령어로 용량 및 로우 수 확인
이 명령어는 _statistics_ DB 내의 모든 내부 테이블에 대해 물리적인 데이터 용량과 전체 로우(Row) 수를 한눈에 보여줍니다.
sql
-- _statistics_ 데이터베이스 전체 테이블의 용량과 로우 수 확인
SHOW DATA FROM _statistics_;
* 체크 포인트: Size 필드가 수 GB 이상이거나, `RowCount`가 수천만 건을 넘어가면 통계 정보가 과도하게 쌓여 있는 것으로 판단할 수 있습니다. 특히 column_statistics 테이블이 가장 비대해지기 쉽습니다.
2. 주요 통계 테이블별 로우 수 확인
직접 SQL을 실행하여 문제가 되는 특정 테이블의 크기를 확인합니다.
sql
-- 1. 가장 핵심적인 통계 정보 테이블 (가장 먼저 확인)
SELECT count(*) FROM _statistics_.column_statistics;
-- 2. 히스토그램 정보 (기능을 사용하는 경우 비대해질 수 있음)
SELECT count(*) FROM _statistics_.histogram_statistics;
-- 3. 테이블 단위 통계 요약
SELECT count(*) FROM _statistics_.table_statistic_v1;
-- 4. (v3.5 이상) 다중 컬럼 결합 통계
SELECT count(*) FROM _statistics_.multi_column_statistics;
3. 판단 기준 (비대함의 척도)
통계 데이터는 클러스터의 테이블/파티션/컬럼 수에 비례하지만, 일반적인 상황에서 다음과 같은 징후가 보이면 "비대하다"고 판단합니다.
* 로우 수: column_statistics 테이블의 로우 수가 *1,000만 건*을 초과하는 경우.
* 지연: DELETE FROM _statistics_... 쿼리가 실행 계획 단계에서 멈추거나 수백 초 이상 소요되는 경우.
* 메타데이터 락: SHOW FULL PROCESSLIST 상에서 root 유저의 통계 관련 쿼리가 다른 쿼리들의 `Planning`을 방해하고 있는 경우.
4. 왜 이렇게 커졌을까?
* 잦은 파티션 생성/삭제: 임시 파티션을 생성했다가 지우는 작업이 반복되면, 해당 파티션의 통계 정보가 제때 정리되지 않고 `_statistics_`에 남을 수 있습니다.
* 모든 컬럼 수집: 모든 테이블의 모든 컬럼에 대해 통계를 수집하도록 설정된 경우 데이터 양이 급증합니다.
* 정리 주기(Cleanup Interval) 문제: 내부적인 Cleanup 로직이 DB 부하로 인해 정상 동작하지 못하면 데이터가 계속 누적됩니다.
조치 팁: 만약 너무 비대해져서 시스템이 마비된 상태라면, `enable_statistic_collect`를 끄고 _statistics_ 테이블의 데이터를 TRUNCATE 하거나 문제가 되는 오래된 데이터를 수동으로 삭제하여 FE의 락 부하를 먼저 해소해야 합니다. (단, 통계 삭제 후에는 쿼리 성능이 일시적으로 떨어질 수 있으므로 주요 테이블은 다시 ANALYZE 해줘야 합니다.)
References
• faq/Sql_faq.md
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/Database/SHOW_DATA.md
References
• using_starrocks/Cost_based_optimizer.md
• knowledge/admin_and_operation/shared_data_compaction.mdRonJay
07/19/2026, 2:18 AMRocky
07/19/2026, 2:19 AMWaiting for lock 현상이 발생합니다.
2. 메타데이터와 로그 디렉터리 분리 (중요)
기본적으로 FE는 메타데이터와 감사 로그(Audit Log)를 같은 디렉터리에 저장할 수 있습니다. 로그 쓰기량이 많아지면 메타데이터 I/O를 방해합니다.
* 조치: FE 설정(fe.conf)에서 `meta_dir`와 로그 관련 경로를 물리적으로 다른 볼륨(PVC)으로 분리하는 것을 검토하세요.
* 효과: 감사 로그 기록으로 인한 메타데이터 업데이트 지연을 방지합니다.
3. 감사 로그(Audit Log) 및 검색 로그 최적화
로그 쓰기 자체를 줄여 I/O 부하를 낮춥니다.
* 조치: `fe.conf`에서 불필요한 로그 수준을 조정하거나, 오래된 로그 삭제 주기를 짧게 가져갑니다.
* `audit_log_modules`: 불필요한 모듈 제외.
* `history_last_day_num`: 감사 로그 보관 기간 단축 (기본 30일 -> 7일 등).
4. BDB JE(Berkeley DB) 튜닝
FE 내부의 메타데이터 데이터베이스 설정을 조정하여 디스크 쓰기 빈도를 최적화할 수 있습니다.
* 조치: `fe.conf`에 아래 설정 추가 (상황에 따라 전문가 검토 필요)
* `edit_log_roll_num`: 에디트 로그를 롤링하는 단위. 너무 작으면 빈번한 파일 생성이 발생합니다.
* 주의: BDB JE 관련 설정은 데이터 안정성과 직결되므로 변경 전 공식 문서나 커뮤니티 확인이 필수입니다.
5. 통계 정보 관리 최적화 (이전 질문 관련)
이전 질문에서 언급된 _statistics_ 테이블 문제도 결국 FE의 메타데이터 I/O 부하를 가중시킵니다.
* 조치: `enable_statistic_collect`를 관리하고, 비대해진 통계 데이터를 정리하여 FE가 관리해야 할 메타데이터 양 자체를 줄여줍니다.
6. FE 스케일 아웃 (High Availability)
만약 FE Leader 혼자 너무 많은 I/O를 감당하고 있다면, Follower FE를 추가하여 읽기 부하를 분산할 수 있습니다. (단, 쓰기 부하는 여전히 Leader에 집중됩니다.)
──────────
요약하자면:
가장 확실하고 빠른 해결책은 *FE 전용 PVC를 고성능 NVMe SSD급으로 업그레이드*하는 것입니다. CN(Compute Node)은 로컬 디스크를 주로 캐시나 임시 데이터 저장용으로 쓰지만, *FE의 디스크 성능은 클러스터의 '생존'과 직결*됩니다.
만약 K8S 환경이라면, FE Pod의 `volumeClaimTemplates`에서 더 높은 성능의 `storageClassName`을 사용하도록 매니 설정하여 재배포하는 것을 권장합니다. (데이터 백업 필수)
References
• administration/management/FE_configuration.md
• deployment/helm.md
• faq/Sql_faq.md
• administration/management/BE_configuration.md
• sql-reference/sql-statements/administration/ADMIN_SET_CONFIG.md
References
• administration/management/FE_configuration.md
• deployment/helm.md
• faq/Sql_faq.md
• administration/management/BE_configuration.md
• sql-reference/sql-statements/administration/ADMIN_SET_CONFIG.md
• introduction/Architecture.md
• administration/Monitor_and_Manage.md
• administration/management/Manage_FE.md
• quick_start/shared-data.md
• administration/Step-by-step_Troubleshooting.md
• using_starrocks/Cost_based_optimizer.md
• administration/Statistics.md
• administration/Configuration.md
• administration/management/Logging.mdRocky
07/19/2026, 2:19 AMRonJay
07/19/2026, 2:35 AMRocky
07/19/2026, 2:35 AMsql
SHOW COMPUTE NODES;
* NumRunningQueries: 해당 CN에서 현재 실행 중인 쿼리 수입니다.
* CpuUsedPct: 해당 CN의 CPU 사용률(%)입니다.
* 전체 백엔드(BE/CN 공통) 확인:
sql
SHOW PROC '/backends';
* `NumRunningQueries`와 CpuUsedPct 컬럼을 통해 동일한 정보를 확인할 수 있습니다.
2. 실행 중인 구체적인 쿼리 내용 확인
어떤 쿼리가 CPU를 많이 쓰고 있는지 상세 정보가 필요할 때 사용합니다.
* 현재 FE에서 관리 중인 쿼리 목록:
sql
SHOW PROC '/current_queries';
-- v3.4 이상에서 모든 FE의 쿼리를 보려면
SHOW PROC '/global_current_queries';
* QueryId, MemoryUsage, CPUTime, ExecTime 등을 확인할 수 있어 어떤 쿼리가 병목인지 파악하기 좋습니다.
* 연결된 세션 상태 확인:
sql
SHOW PROCESSLIST;
3. Kubernetes 레벨에서 확인 (Pod별 물리 자원)
StarRocks 엔진 내부 수치와 별개로, Pod가 실제로 소비하는 물리적 자원량을 확인하고 싶을 때 사용합니다.
bash
# 특정 CN Pod의 실시간 자원 사용량 확인
kubectl top pod <cn-pod-name> -n <namespace>
* CPU (cores): 해당 Pod가 실제 사용 중인 CPU 코어 수입니다.
4. 프로메테우스(Prometheus) 메트릭 활용
모니터링 시스템이 구축되어 있다면 아래 메트릭을 Grafana에서 조회할 수 있습니다.
* 쿼리 수: starrocks_be_query_execution_count (누적값) 또는 현재 실행 중인 수치.
* CPU 사용량: starrocks_be_cpu_usage
요약:
가장 간단한 확인법은 SHOW COMPUTE NODES; 쿼리를 실행하여 `NumRunningQueries`와 CpuUsedPct 컬럼을 확인하는 것입니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md
• using_starrocks/running_queries.md
• administration/management/resource_management/query_queues.md
References
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md
• using_starrocks/running_queries.md
• administration/management/resource_management/query_queues.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
• administration/management/monitoring/Monitor_and_Alert.md
References
• using_starrocks/running_queries.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md
• administration/management/resource_management/query_queues.md
• sql-reference/information_schema/be_threads.mdRonJay
07/19/2026, 2:45 AMRocky
07/19/2026, 2:46 AMexternalFull 10/15 실패)
* 상황: 전체 15건의 externalFull 통계 수집 작업 중 *10건이 실패*했습니다. 실패율이 66%에 달합니다.
* 의미: `externalFull`은 외부 테이블(Hive, Iceberg 등)의 전체 데이터를 스캔하여 통계를 내는 *매우 무거운 작업*입니다.
* 실패 원인 추정:
1. I/O 타임아웃: FE의 PVC가 느려 통계 정보를 쓰고 읽는 과정에서 타임아웃 발생.
2. 리소스 부족: FE가 329개의 쿼리를 처리하느라 백그라운드 작업인 통계 수집에 자원을 할당하지 못함.
3. 외부 카탈로그 지연: 외부 메타스토어와의 통신 문제.
3. 해결을 위한 권장 조치
① 통계 수집 작업 상태 확인 (실패 원인 파악)
어떤 이유로 실패했는지 정확한 메시지를 확인해야 합니다.
sql
SHOW ANALYZE STATUS WHERE Status = 'FAILED';
* Reason 컬럼에 'Timeout', 'Memory exceed', 'Lock wait timeout' 등의 메시지가 있는지 확인하세요.
② 과도한 통계 수집 제한 (임시 조치)
만약 v3.4 이상을 사용 중이고 쿼리에 의해 자동으로 통계 수집이 유발되고 있다면, 잠시 꺼두어 FE의 숨통을 틔워줄 수 있습니다.
sql
SET GLOBAL enable_query_trigger_analyze = false;
③ 쿼리 큐(Query Queue) 적용 범위 확대
현재 10개만 큐에 들어가고 나머지는 무방비로 들어오고 있습니다. 리소스 그룹 설정을 통해 동시 실행 쿼리 수를 제한하여 FE를 보호해야 합니다.
* 효과: FE가 한 번에 Planning해야 할 양을 줄여 PVC 부하를 분산합니다.
④ (가장 중요) FE PVC 업그레이드
현재의 지표(많은 쿼리 수 + 무거운 통계 작업 실패)는 FE의 메타데이터 처리 능력이 한계에 도달했음을 보여줍니다. *SSD급 고성능 스토리지로의 교체*가 이 병목을 해결하는 가장 근본적인 방법입니다.
요약: 329개의 쿼리가 한꺼번에 FE를 때리고 있는데, 무거운 외부 테이블 통계 작업까지 실패하며 FE가 고전하고 있습니다. *쿼리 큐를 강화*하여 진입 쿼리 수를 조절하고, *통계 수집 부하를 제어*하면서 *PVC 성능 개선*을 추진하십시오.
References
• using_starrocks/Cost_based_optimizer.md
• administration/management/resource_management/query_queues.md
• using_starrocks/running_queries.md
References
• using_starrocks/Cost_based_optimizer.md
• administration/management/resource_management/query_queues.md
• using_starrocks/running_queries.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md
• administration/Meta_recovery.md
References
• using_starrocks/Cost_based_optimizer.mdRonJay
07/19/2026, 2:48 AMRocky
07/19/2026, 2:48 AMReason 컬럼을 확인해 보세요.
sql
-- 실패한 작업들만 골라서 실패 원인 확인
SHOW ANALYZE STATUS WHERE Status = 'FAILED';
결과에 따른 조치:
* `Reason`에 *"Timeout"*이 많다면: FE PVC 성능 개선이 시급합니다.
* *"Memory exceed"*가 있다면: CN의 메모리 부족이 원인입니다.
* *"Lock wait timeout"*이 있다면: FE에 몰린 쿼리 부하(329개)를 줄여야 합니다.
팁: 너무 많은 externalFull 작업이 실패하고 있다면, 우선 순위가 낮은 통계 수집은 잠시 중단하거나(KILL ANALYZE [ID]), 수집 주기를 조정하여 FE의 부하를 줄여주는 것이 좋습니다.
References
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md
• using_starrocks/Cost_based_optimizer.md
• sql-reference/information_schema/analyze_status.md
References
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md
• using_starrocks/Cost_based_optimizer.md
• sql-reference/information_schema/analyze_status.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md
References
• sql-reference/information_schema/analyze_status.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.mdRonJay
07/19/2026, 2:56 AMRocky
07/19/2026, 2:56 AMtxn_request: BEGIN, COMMIT, ROLLBACK 등의 트랜잭션 요청 횟수입니다.
* starrocks_fe_txn_total_latency_ms: 트랜잭션이 시작(Prepare)되어 최종 완료(Finish)될 때까지의 *전체 소요 시간*입니다.
② 단계별 지연 시간 (상세 진단용)
트랜잭션은 크게 *Write(쓰기)*와 Publish(발행) 두 단계로 나뉩니다.
* starrocks_fe_txn_write_latency_ms: 데이터를 실제로 BE에 쓰고 `COMMIT`을 준비하기까지의 시간입니다.
* starrocks_fe_txn_publish_latency_ms: COMMIT 직후부터 데이터가 실제 쿼리에서 조회 가능해지는(VISIBLE) 상태가 될 때까지의 시간입니다.
* 사용자님 상황에서 매우 중요: 이 수치가 높다면 FE가 메타데이터를 갱신하고 새 버전을 발행하는 과정에서 PVC 병목이나 락 경합이 발생하고 있다는 증거입니다.
③ Publish 세부 단계 (v4.0+ 에서 더욱 상세화)
Publish 지연이 높을 때 구체적으로 어디가 느린지 보여줍니다:
* publish_schedule_latency: 트랜잭션이 커밋된 후 FE의 발행 큐에서 대기하는 시간.
* publish_execute_latency: 실제 발행 작업이 실행되는 시간.
* publish_ack_latency: BE들로부터 발행 완료 응답을 모두 받고 최종적으로 VISIBLE 상태로 마킹하는 데 걸리는 시간.
2. 현재 상황에서의 해석 가이드
제공해주신 FE의 과부하 상태(Query 329개, PVC 저하)와 연결해 보면 다음과 같은 현상이 나타날 수 있습니다:
1. Publish Latency 상승: FE가 새로운 데이터 버전을 BDB JE(메타데이터 저장소)에 기록해야 하는데, PVC가 느리면 이 단계에서 지연이 발생합니다.
2. Lock 경합: FE는 트랜잭션 완료 시 메타데이터 락을 잡습니다. 실행 중인 쿼리가 너무 많으면(329개) 이 락을 얻기 위해 대기 시간이 길어지며 `txn_total_latency`가 급증합니다.
3. 성능 저하 순환: 트랜잭션 처리가 늦어지면 FE 메모리에 트랜잭션 정보가 더 오래 머물게 되고, 이는 다시 FE의 전체적인 성능 저하로 이어집니다.
3. 확인 방법
Prometheus/Grafana가 있다면 아래 쿼리로 지연 시간의 추이를 확인해 보세요.
* 전체 평균 지연: rate(starrocks_fe_txn_total_latency_ms_sum[5m]) / rate(starrocks_fe_txn_total_latency_ms_count[5m])
결론적으로, TXN 메트릭은 StarRocks가 데이터를 얼마나 빨리 안전하게 저장하고 있는지를 보여주는 지표입니다. 현재처럼 FE 부하가 높은 상황에서는 *`publish_latency`*가 평소보다 튀지 않는지 모니터링하는 것이 가장 중요합니다.
References
• administration/management/monitoring/metrics.md
• administration/management/FE_configuration.md
• sql-reference/information_schema/be_txns.md
References
• administration/management/monitoring/metrics.md
• administration/management/FE_configuration.md
• sql-reference/information_schema/be_txns.md
• administration/Meta_recovery.md
• loading/StreamLoad.md
References
• administration/management/monitoring/metrics.md
• administration/management/FE_configuration.md
• sql-reference/information_schema/be_txns.mdRonJay
07/19/2026, 2:59 AMRocky
07/19/2026, 2:59 AMfe.audit.log 파일을 확인하여 어떤 단계에서 시간이 소요되는지 확인하세요.
* `PlanTime`이 높음: FE의 쿼리 최적화 및 메타데이터 조회 단계가 느린 것입니다. 현재 사용자님의 상황(느린 PVC + 329개 쿼리)에서는 이 가능성이 매우 높습니다.
* `QueryTime`은 높지만 `PlanTime`은 낮음: 데이터 스캔이나 조인 연산 등 BE(Storage/Compute) 단계가 느린 것입니다.
──────────
2단계: 실시간 실행 쿼리 상태 확인
어떤 쿼리들이 자원을 점유하고 있는지 확인합니다.
sql
-- 현재 실행 중인 쿼리와 각 쿼리의 진행 시간 확인
SHOW PROC '/current_queries';
* 여기서 `ScanBytes`나 `CpuCost`가 비정상적으로 높은 쿼리가 있다면 해당 쿼리가 전체 시스템의 IO나 CPU를 점유하고 있는 것입니다.
──────────
3단계: FE 내부 병목 진단 (사용자 상황 특화)
현재 *329개의 쿼리*가 돌아가고 있는데 *큐 슬롯은 10개*만 사용 중이라는 점은 매우 위험한 신호입니다.
① FE Lock 경합 확인
FE는 메타데이터를 읽고 쓸 때 Lock을 사용합니다. 쿼리가 너무 많으면 Lock 대기 시간이 길어집니다.
sql
SHOW PROC '/fe_locks';
* `WaitTime`이 긴 Lock이 있는지 확인하세요. 만약 특정 쿼리가 Lock을 오래 잡고 있다면 전체 쿼리가 Planning 단계에서 멈추게 됩니다.
② JVM GC 상태 확인
FE 메모리(Heap)가 부족하면 Garbage Collection이 빈번하게 발생하여 모든 처리가 중단(Stop-the-world)될 수 있습니다.
* fe.gc.log.0 파일에서 `Full GC`가 발생하고 있는지 확인하세요. 329개의 쿼리 객체가 메모리에 올라와 있다면 GC 부하가 상당할 것입니다.
──────────
4단계: 개별 쿼리 상세 분석 (Profile)
가장 느린 특정 쿼리 하나를 골라 상세 분석합니다.
sql
-- 1. 프로파일 수집 활성화
SET is_report_success = true;
-- 2. 느린 쿼리 실행 (또는 실행 중인 쿼리 ID 확인)
-- 3. 프로파일 결과 확인
-- 웹 UI(<http://FE_IP:8030/query>)에서 확인하는 것이 가장 직관적입니다.
* 프로파일에서 *`PendingTime`*이 길다면 쿼리 큐 대기, *`ScheduleTime`*이 길다면 BE 할당 대기, *`ScanTime`*이 길다면 디스크 IO 병목입니다.
──────────
5단계: 긴급 조치 (Stop the Bleeding)
지금 당장 시스템을 정상화해야 한다면 다음 조치를 권장합니다.
1. 부하가 큰 쿼리 강제 종료: `SHOW PROC '/current_queries'`에서 실행 시간이 비정상적으로 길거나 자원을 많이 먹는 쿼리 ID를 찾아 KILL QUERY [ID] 하세요.
2. 리소스 그룹 설정 재검토: 왜 329개의 쿼리가 큐(10개 제한)를 무시하고 실행되고 있는지 확인해야 합니다. (Default Group에 제한이 없거나, bypass_query_queue 옵션이 켜져 있을 수 있습니다.)
3. 통계 수집 일시 중지: 앞서 확인한 것처럼 실패하는 externalFull 통계 수집 작업이 FE에 추가 부하를 주고 있으므로 잠시 멈추는 것이 좋습니다.
요약하자면: 먼저 `fe.audit.log`의 `PlanTime`을 보고 *FE 자체의 문제(Lock/PVC/GC)*인지, 아니면 *BE의 자원 부족*인지를 판단하는 것이 문제 해결의 시작점입니다.
References
• administration/management/monitoring/Audit_log.md
• administration/management/resource_management/query_queues.md
• administration/management/monitoring/Query_profile_overview.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• faq/Sql_faq.md
References
• administration/management/monitoring/Audit_log.md
• administration/management/resource_management/query_queues.md
• administration/management/monitoring/Query_profile_overview.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• faq/Sql_faq.md
• using_starrocks/Query_planning.mdRocky
07/19/2026, 2:59 AMRonJay
07/19/2026, 3:04 AMRocky
07/19/2026, 3:04 AMKILL 명령어를 실행*해야 합니다.
1. 실행 중인 쿼리와 ID 확인하기
가장 먼저 어떤 쿼리가 자원을 먹고 있는지 확인합니다. 아래 명령어 중 하나를 사용하세요.
* 방법 A (추천): 리소스 사용량까지 한눈에 확인
sql
SHOW PROC '/current_queries';
* 여기서 ConnectionId 또는 QueryId 컬럼을 확인하세요.
* 방법 B: 표준 MySQL 방식
sql
SHOW FULL PROCESSLIST;
* 여기서 Id 컬럼이 해당 세션의 ID입니다.
──────────
2. 쿼리 종료하기 (KILL)
확인한 ID를 사용해 쿼리를 중단시킵니다.
* 특정 쿼리만 종료 (연결은 유지):
sql
-- ConnectionId가 12345인 경우
KILL QUERY 12345;
* 해당 연결(세션) 자체를 강제 종료:
sql
-- ConnectionId가 12345인 경우
KILL 12345;
──────────
3. 한꺼번에 정리하고 싶을 때 (주의)
만약 10개가 아니라 너무 많은 쿼리가 쌓여서 하나하나 지우기 힘들다면, FE(Frontend) 프로세스를 재시작하는 방법이 가장 확실하지만 서비스 중단이 발생하므로 신중해야 합니다.
팁: 현재 329개의 쿼리가 대기 중이고 10개만 실행 중이라면, 실행 중인 10개를 죽여도 대기 중인 쿼리들이 즉시 슬롯을 다시 채울 가능성이 높습니다.
* 문제가 되는 쿼리 패턴을 찾아서 *원천적인 요청을 차단*하거나,
* 리소스 그룹(Resource Group) 설정을 통해 특정 유저나 쿼리가 슬롯을 독점하지 못하도록 `concurrency_limit`을 조정하는 것을 권장합니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md
• administration/management/monitor_manage_big_queries.md
• administration/management/resource_management/Query_management.md
• using_starrocks/running_queries.md
References
• sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md
• administration/management/monitor_manage_big_queries.md
• administration/management/resource_management/Query_management.md
• using_starrocks/running_queries.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
• administration/management/resource_management/query_queues.md
• administration/management/resource_management/Resource_group.md
• faq/Sql_faq.md
References
• sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md
• administration/management/monitor_manage_big_queries.md
• administration/management/resource_management/Query_management.md
• using_starrocks/running_queries.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.mdRocky
07/19/2026, 3:04 AMRonJay
07/19/2026, 4:18 AMRocky
07/19/2026, 4:18 AMALTER RESOURCE GROUP 명령어를 사용하여 spill_mem_limit_threshold 값을 수정합니다. 이 값은 해당 리소스 그룹에 할당된 메모리 중 어느 정도를 사용했을 때 디스크로 데이터를 흘릴(Spill) 것인지를 결정하는 비율(0~1)입니다.
sql
-- default_wg의 spill 임계치를 80%로 설정
ALTER RESOURCE GROUP default_wg WITH (
'spill_mem_limit_threshold' = '0.8'
);
2. 설정 전 필수 체크사항 (Prerequisites)
Spill 기능이 실제로 작동하려면 리소스 그룹 설정 외에 아래 환경 설정이 완료되어 있어야 합니다.
1. BE 설정 (be.conf): 데이터를 저장할 디스크 경로가 지정되어야 합니다.
* spill_local_storage_dir=/data1/spill;/data2/spill (여러 디스크 권장)
* 설정 후 BE 재시작이 필요합니다.
2. 세션 변수 활성화:
sql
SET GLOBAL enable_spill = true;
SET GLOBAL spill_mode = 'auto'; -- 자동으로 임계치 도달 시 작동
3. 설정 가이드 및 권장 사항
① 임계치 작동 원리
`default_wg`의 경우 기본적으로 `mem_limit`이 100%로 설정되어 있습니다. 따라서 다음과 같은 공식으로 Spill이 트리거됩니다:
트리거 시점 =② 권장 값 (Best Practice) * 0.8 ~ 0.9 (80-90%): 가장 권장되는 수치입니다. 메모리 부족으로 인한 OOM(Out of Memory)을 방지하면서도, 가급적 메모리 내에서 연산을 처리하여 성능 저하를 최소화합니다. * 0.5 ~ 0.7 (50-70%): 메모리가 매우 부족한 환경이거나, 쿼리의 복잡도가 높아 갑작스러운 메모리 점유율 상승이 잦은 경우에 설정합니다. 단, 빈번한 디스크 I/O로 인해 전체적인 쿼리 성능은 떨어집니다. * 1.0 (기본값): 사실상 그룹 차원의 Spill 기능을 끄는 것과 같습니다. 개별 쿼리 단위의 제한(80%)에 의존하게 됩니다. ③ 고려해야 할 상황 * 디스크 성능: Spill은 디스크 I/O를 대량으로 발생시킵니다. 데이터 저장용 디스크와 별도의 고성능 NVMe/SSD 디스크를 Spill 전용 경로로 지정하는 것이 좋습니다. * default_wg의 특성: 대부분의 일반 쿼리가 이 그룹을 사용하므로, 이 값을 너무 낮게 잡으면 멀쩡한 쿼리들도 디스크를 사용하여 시스템 전체가 느려질 수 있습니다. 우선 0.8 정도로 시작하여 모니터링 후 조정하시기 바랍니다. 4. 설정 확인 명령어 설정이 잘 반영되었는지 확인하려면 아래 명령어를 사용하세요.×BE 전체 쿼리 메모리 제한×mem_limit(1.0)spill_mem_limit_threshold
sql
SHOW RESOURCE GROUPS;
References
• administration/management/resource_management/resource_group.md
• administration/management/resource_management/spill_to_disk.md
• sql-reference/System_variable.md
• administration/management/BE_configuration.md
References
• administration/management/resource_management/resource_group.md
• administration/management/BE_configuration.md
• sql-reference/System_variable.md
• administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/Memory_management.mdRonJay
07/19/2026, 4:55 AMsql
-- default_wg의 spill 임계치를 80%로 설정
ALTER RESOURCE GROUP default_wg WITH (
'spill_mem_limit_threshold' = '0.8'
);Rocky
07/19/2026, 4:55 AMspill_mem_limit_threshold 값과 상관없이 *모든 대상 연산자가 무조건 디스크로 데이터를 흘리도록(Spill) 작동*합니다.
구체적인 동작 방식과 주의사항은 다음과 같습니다.
1. FORCE 모드의 동작 방식
* 임계치 무시: 설정하신 spill_mem_limit_threshold = 0.8 수치를 체크하지 않습니다. 메모리가 아주 넉넉하게 남아 있더라도, Spill이 가능한 연산자(Join, Aggregate, Sort 등)를 만나는 즉시 데이터를 디스크에 쓰기 시작합니다.
* 메모리 최소 점유: 메모리 사용량을 최소화하려는 목적일 때 사용합니다. 데이터를 거의 메모리에 담아두지 않고 바로 디스크로 내보내기 때문입니다.
* 성능 저하: 메모리 연산 대신 디스크 I/O를 강제로 발생시키므로, auto 모드나 Spill을 쓰지 않을 때보다 쿼리 속도가 수 배에서 십수 배까지 느려질 수 있습니다.
2. 설정 간의 상관관계 요약
설정 항목 | spill_mode = 'auto' (기본값) | spill_mode = 'force'
작동 시점 | RG 메모리의 80% 사용 시점부터 Spill | 쿼리 시작 즉시 Spill
임계치(0.8) 영향 | 직접적인 기준점이 됨 | 무시됨
주요 용도 | OOM 방지 및 안정적 운영 | 디스크 Spill 강제 테스트 또는 극단적인 메모리 절약
3. 권장 가이드
현재 300개가 넘는 쿼리가 실행 중인 상황에서 force 모드를 사용하면, 모든 쿼리가 동시에 디스크 I/O를 일으켜 전체 시스템의 스토리지 부하가 감당하기 어려울 정도로 높아질 수 있습니다.
* 일반적인 상황: `spill_mode = 'auto'`를 권장합니다. 평소에는 메모리로 빠르게 처리하다가, 정말 메모리가 부족해지는 시점(80%)에만 안전하게 Spill을 시작하게 됩니다.
* FORCE가 필요한 경우: 특정 쿼리가 너무 커서 무조건 OOM이 발생할 것이 확실할 때, 해당 세션에서만 `SET spill_mode = 'force';`를 실행하여 쿼리를 끝까지 완수시키는 용도로만 사용하는 것이 좋습니다.
결론적으로: `ALTER RESOURCE GROUP`으로 임계치를 0.8로 설정하셨다면, 시스템 변수는 `SET GLOBAL spill_mode = 'auto';`로 유지하는 것이 성능과 안정성 사이의 가장 좋은 균형점입니다.
References
• sql-reference/System_variable.md
• administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/resource_group.md
References
• sql-reference/System_variable.md
• administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/resource_group.md
• administration/management/BE_configuration.md
• administration/management/resource_management/Memory_management.md
References
• sql-reference/System_variable.md
• administration/management/BE_configuration.md
• administration/management/resource_management/resource_group.md
• administration/management/resource_management/spill_to_disk.mdRonJay
07/19/2026, 4:57 AMRocky
07/19/2026, 5:01 AMsql
ALTER RESOURCE GROUP default_wg WITH (
'spill_mem_limit_threshold' = '0.8'
);
2. 버전 4.0.x 관련 확인 사항
StarRocks 4.0 버전에서도 spill_mem_limit_threshold 프로퍼티는 여전히 유효합니다 (v3.1.7부터 도입). 하지만 만약 철자를 맞게 썼음에도 에러가 계속된다면 다음 두 가지를 확인해 보시기 바랍니다.
* 시스템 설정 확인: 리소스 그룹 기능 자체가 활성화되어 있는지 확인이 필요할 수 있습니다. (하지만 보통 `default_wg`가 존재하면 활성화된 상태입니다.)
* 지원 속성 확인: 현재 사용 중인 버전에서 리소스 그룹이 지원하는 정확한 컬럼명들을 확인하려면 아래 명령어를 사용해 보세요.
sql
SHOW RESOURCE GROUPS ALL;
출력 결과의 컬럼 헤더에 `spill_mem_limit_threshold`가 있는지 확인하시면 됩니다.
요약
에러 메시지에 나타난 spill_mem_limit_threshhold (h가 두 개)는 잘못된 이름입니다. spill_mem_limit_threshold (h가 한 개)로 수정하시면 4.0.4 버전에서도 정상적으로 작동합니다.
References
• administration/management/resource_management/resource_group.md
• sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md
• sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md
References
• administration/management/resource_management/resource_group.md
• sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md
• sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md
• administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/resource_group.md
• sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md
• sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md
• administration/management/resource_management/spill_to_disk.md
• administration/management/BE_configuration.md
• sql-reference/System_variable.md
• administration/management/resource_management/Memory_management.md
• releasenotes/releasenotes.md
• faq/Resource_group_faq.md
• administration/management/resource_management/Query_management.md
• sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.mdRocky
07/19/2026, 5:01 AMRocky
07/19/2026, 5:01 AMRocky
07/19/2026, 5:01 AMRocky
07/19/2026, 5:01 AMRocky
07/19/2026, 5:01 AMRocky
07/19/2026, 5:01 AMRocky
07/19/2026, 5:01 AMRocky
07/19/2026, 5:01 AMRocky
07/19/2026, 5:01 AMRonJay
07/19/2026, 5:08 AMRocky
07/19/2026, 5:09 AMquery_queue_mem_used_pct_limit, spill_mem_limit_threshold)이 함께 작동할 때의 메모리 처리 로직은 "신규 진입 차단(Queue) 후 기존 쿼리 보호(Spill)" 순서로 진행됩니다.
사용자께서 설정하신 시나리오(Queue 0.6 / Spill 0.8)를 기준으로 시계열 로직을 설명해 드리겠습니다.
──────────
1단계: 메모리 점유율 60% 도달 (query_queue_mem_used_pct_limit = 0.6)
* 로직: 대기열(Admission Control) 작동
* 동작:
* 해당 리소스 그룹(RG)의 메모리 사용량이 60%를 넘어서는 순간, *새로 들어오는 쿼리*는 실행되지 않고 큐(Queue)에서 대기 상태(Pending)가 됩니다.
* *이미 실행 중인 쿼리*들은 중단되지 않고 그대로 메모리를 사용하며 작업을 계속합니다.
* 목적: 새로운 작업 부하를 차단하여 메모리 사용량이 급격히 치솟는 것을 방지합니다.
2단계: 메모리 점유율 상승 (60% ~ 80% 사이)
* 상태: 신규 쿼리는 차단되었지만, 이미 실행 중인 쿼리들이 연산을 수행하면서 메모리를 추가로 점유할 수 있습니다.
* 동작: 아직 80%에 도달하지 않았으므로, 모든 연산은 여전히 *메모리 내(In-Memory)*에서 처리됩니다.
3단계: 메모리 점유율 80% 도달 (spill_mem_limit_threshold = 0.8)
* 로직: Spill(디스크 스왑) 트리거
* 동작:
* 리소스 그룹의 메모리 점유율이 80%에 도달하면, 실행 중인 쿼리 내의 *Spill 가능 연산자(Aggregate, Sort, Join 등)*가 작동 모드를 전환합니다.
* 메모리에 있는 중간 데이터(Intermediate data)를 BE/CN의 spill_local_storage_dir 경로에 지정된 디스크로 내려쓰기 시작합니다.
* 조건: 이 로직이 작동하려면 세션 변수 enable_spill = true 및 spill_mode = 'auto' 설정이 되어 있어야 합니다.
* 목적: 메모리 부족으로 인한 OOM(Out of Memory) 킬을 방지하고, 속도는 느려지더라도 쿼리를 끝까지 완수시킵니다.
4단계: 메모리 해제 및 복구
* 로직: 작업 완료 후 메모리 반환
* 동작:
* 실행 중이던 쿼리가 종료되어 메모리 점유율이 80% 미만으로 떨어지면 Spill이 멈춥니다.
* 점유율이 다시 60% 미만으로 떨어지면, 큐에서 대기 중이던 신규 쿼리들이 순차적으로 실행 모드로 들어갑니다.
──────────
요약 가이드 (사용자 설정 평가)
사용자께서 설정하신 *Queue 0.6 / Spill 0.8*은 매우 *보수적이고 안정적인 설정*입니다.
1. 안전성: 메모리가 60%만 차도 신규 유입을 막고, 혹시 모를 오버플로우가 80%에 도달하면 디스크를 써서라도 버티기 때문에 시스템이 뻗을(Crash) 확률이 매우 낮습니다.
2. 성능 고려: 다만, 동시 쿼리가 많은 환경이라면 60% 임계치 때문에 쿼리가 자주 대기열에 걸릴 수 있습니다.
* 시스템 여유가 있다면 Queue 임계치를 *0.7~0.8*로 높이고, Spill 임계치를 0.9 정도로 조정하여 메모리 활용도를 극대화하는 것도 방법입니다.
주의사항:
CN 노드를 사용 중이시라면, CN은 로컬 디스크가 없는 경우가 많습니다. Spill을 사용하려면 CN 노드에도 반드시 *데이터를 기록할 수 있는 로컬 디스크 경로(`be.conf`의 spill_local_storage_dir)가 마운트*되어 있어야 함을 유의하세요.
References
• administration/management/resource_management/resource_group.md
• administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/query_queues.md
• sql-reference/System_variable.md
References
• administration/management/resource_management/resource_group.md
• administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/query_queues.md
• sql-reference/System_variable.md
• administration/management/BE_configuration.md
• administration/management/resource_management/Memory_management.md
• administration/management/resource_management/Query_management.mdRonJay
07/19/2026, 8:19 AMRocky
07/19/2026, 8:23 AMA + B 같은 복잡한 수식을 계산하는 과정에서 쓰는 일시적인 메모리는 Spill이 안 됩니다.
* Fixed Overheads: 쿼리 실행을 위한 실행 계획(Plan) 정보나 스레드 스택 등.
결론적으로:
Disk Spill은 Process Memory > Query Memory > Operator Data(Hash Table/Sort Buffer) 순으로 타고 내려가서, 가장 덩치가 큰 *연산 중간 결과값*만 핀포인트로 디스크에 옮기는 로직입니다.
References
• administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/Memory_management.md
• sql-reference/System_variable.md
References
• administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/Memory_management.md
• sql-reference/System_variable.md
• administration/management/BE_configuration.md
• administration/management/resource_management/resource_group.md
• administration/management/resource_management/Query_management.md
• using_starrocks/caching/query_cache.md
• administration/management/resource_management/query_queues.md
• releasenotes/releasenotes.md
• faq/Resource_group_faq.md
• quick_start/shared_nothing.md
• sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md
• sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.mdRocky
07/19/2026, 8:23 AMRocky
07/19/2026, 8:23 AMRocky
07/19/2026, 8:23 AMRocky
07/19/2026, 8:23 AMRocky
07/19/2026, 8:23 AMRocky
07/19/2026, 8:23 AMRocky
07/19/2026, 8:23 AMRocky
07/19/2026, 8:23 AMRocky
07/19/2026, 8:23 AMRonJay
07/20/2026, 12:22 AMRocky
07/20/2026, 12:26 AMstarrocks_fe_query_latency_ms: 쿼리당 평균 지연 시간 (ms).
* starrocks_fe_query_latency_ms_p99: 상위 1% 쿼리의 지연 시간. 시스템의 꼬리 지연(Tail Latency)을 파악하는 데 가장 중요합니다.
* starrocks_fe_query_latency_ms_p90: 상위 10% 쿼리의 지연 시간.
* starrocks_fe_query_latency_ms_p50: 중간값(Median) 지연 시간.
2. 쿼리 처리 속도 (Throughput/QPS) 관련 메트릭
초당 몇 개의 쿼리가 처리되고 있는지를 나타냅니다.
* starrocks_fe_query_total: 시스템 시작 후 누적된 총 쿼리 수.
_ _계산법:* `irate(starrocks_fe_query_total[1m])`를 사용하여 *QPS(초당 쿼리 수)*를 계산합니다.
* starrocks_fe_query_err: 실행 중 에러가 발생한 쿼리 수.
* 전체 쿼리 대비 에러 쿼리 비중을 통해 시스템의 안정성을 체크합니다.
3. 리소스 그룹(Resource Group)별 메트릭
앞서 질문하신 Spill이나 쿼리 큐와 관련하여, 특정 워크로드별 속도를 알려면 아래 메트릭이 유용합니다.
* starrocks_fe_resource_group_query_latency: 특정 리소스 그룹 내의 쿼리 지연 시간.
* starrocks_fe_resource_group_query_total: 특정 리소스 그룹의 총 쿼리 수.
* starrocks_fe_resource_group_query_err: 특정 리소스 그룹의 쿼리 에러 수.
4. 쿼리 큐(Query Queue) 대기 관련 (지연의 원인 파악)
쿼리가 실제 실행되지 못하고 큐에서 대기하며 발생하는 지연을 확인합니다.
* starrocks_fe_query_queue_pending_queries: 현재 큐에서 대기 중인 쿼리 수.
* starrocks_fe_query_queue_total_queued_queries: 큐에 들어갔던 총 쿼리 수.
──────────
추천 확인 방법
1. Grafana 대시보드: StarRocks에서 제공하는 공식 Grafana 대시보드 템플릿을 임포트하면 위 지표들이 시각화되어 있어 한눈에 파악하기 쉽습니다.
2. Audit Log: 개별 쿼리 단위의 정확한 실행 시간을 보려면 FE의 fe/log/fe.audit.log 파일에서 QueryTime 컬럼을 확인하십시오.
References
• administration/management/monitoring/metrics.md
• administration/management/monitoring/Audit_log.md
• administration/management/monitor_manage_big_queries.md
References
• administration/management/monitoring/metrics.md
• administration/management/monitoring/Audit_log.md
• administration/management/monitor_manage_big_queries.md
• administration/management/monitoring/Query_detail_overview.md
• administration/management/monitoring/Query_profile_overview.md
• releasenotes/releasenotes.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md
• using_starrocks/running_queries.md
• administration/management/resource_management/resource_group.md
• faq/Sql_faq.md
• administration/management/resource_management/query_queues.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
• releasenotes/4.0.mdRocky
07/20/2026, 12:26 AMRocky
07/20/2026, 12:26 AMRocky
07/20/2026, 12:26 AMRocky
07/20/2026, 12:26 AMRocky
07/20/2026, 12:26 AMRocky
07/20/2026, 12:26 AMRocky
07/20/2026, 12:26 AMRocky
07/20/2026, 12:26 AMRocky
07/20/2026, 12:26 AMRonJay
07/20/2026, 12:58 AMRocky
07/20/2026, 12:58 AMquery_queue_mem_used_pct_limit 0.8의 영향
사용자께서 말씀하신 query_queue_mem_used_pct_limit = 0.8 설정은 이 상황에서 다음과 같은 의미를 갖습니다.
* 현재 상태: 전체 메모리 대비 사용량 비율이 약 81.4% (42.21 / 51.84)입니다.
* 큐(Queue) 작동 여부: 설정값이 0.8(80%)이므로, *이 시점에 새로 들어오는 쿼리들은 모두 Pending(대기) 상태*로 들어갔을 것입니다.
* 직접적 영향: 이 설정은 *새로운 쿼리의 진입을 막는 역할*이지, 이미 실행 중인 쿼리를 강제로 죽이는 설정은 아닙니다. 하지만 이미 실행 중인 쿼리가 80%를 넘어서서 메모리를 더 쓰려고 하면, 시스템은 위 에러처럼 물리적인 `mem_limit`에 걸려 쿼리를 취소하게 됩니다.
3. 왜 Used와 Limit이 다르게 나오는가? (과거와 다른 이유)
과거에는 조금씩 메모리를 갉아먹다가 딱 Limit에 걸렸을 때 에러가 났다면, 이번에는 *쿼리 연산자(예: Hash Join, 대량 정렬 등)가 한 번에 12.3GB라는 거대한 메모리 블록을 요청*했기 때문입니다.
* 계단식 상승: 메모리를 조금씩 늘리는 게 아니라, 특정 연산 단계에서 "자, 이제 12GB 더 필요해!"라고 요청하는 순간, 시스템은 "그거 주면 나 51GB 넘어가서 안 돼"라고 거절한 것입니다.
* 이 때문에 `Used`가 `Limit`보다 한참 낮은 상태(약 42GB)임에도 불구하고 에러가 발생한 것처럼 보이게 됩니다.
4. 해결을 위한 가이드
현재 상황은 *프로세스 전체 메모리가 부족하거나, 특정 쿼리가 너무 과도한 메모리를 한 번에 요청*하고 있습니다.
1. 리소스 그룹 메모리 제한 확인: 만약 특정 Resource Group을 사용 중이라면 해당 그룹의 `mem_limit`이 BE 전체 메모리보다 작게 설정되어 있는지 확인하세요.
2. Spill 설정 활성화: 이전 질문에서 언급하신 Spill 기능을 켜두셨다면, `spill_mem_limit_threshold`를 query_queue 설정보다 조금 낮게(예: 0.7) 설정하여, 메모리가 80% 차기 전에 미리 디스크를 쓰도록 유도하는 것이 좋습니다.
3. 쿼리 튜닝: 12GB를 한 번에 요청하는 연산이 무엇인지(주로 Join) 확인하고, 파티셔닝이나 조인 순서 변경을 검토해야 합니다.
4. BE mem_limit 상향: 서버에 여유가 있다면 `be.conf`에서 mem_limit 자체를 조금 더 높여주는 것도 방법입니다.
요약하자면: query_queue 설정 때문에 죽은 것이 아니라, *이미 메모리가 80% 이상 차 있는 위험한 상태*에서 실행 중이던 쿼리가 *덩치 큰 메모리 할당을 요청*했다가 물리적인 상한선에 걸려 취소된 것입니다.
References
• administration/management/BE_configuration.md
• administration/management/resource_management/query_queues.md
• administration/management/resource_management/Memory_management.md
• sql-reference/System_variable.mdRonJay
07/20/2026, 3:12 AMRocky
07/20/2026, 3:12 AMdefault_wg)의 특정 속성을 초기화(Reset)하는 별도의 "UNSET" 명령어나 "DROP" 명령은 StarRocks에 존재하지 않습니다. 따라서 *해당 속성의 기본값(Default value)으로 다시 `ALTER`를 수행*하여 초기화해야 합니다.
spill_mem_limit_threshold 속성의 기본값은 *`1` (또는 1.0)*이며, 이는 리소스 그룹 차원의 Spill 임계치를 사실상 비활성화(사용하지 않음) 상태로 두는 것을 의미합니다.
1. 초기화 명령어
다음 명령어를 실행하여 원래의 기본값인 `1`로 되돌릴 수 있습니다.
sql
ALTER RESOURCE GROUP default_wg WITH ( 'spill_mem_limit_threshold' = '1' );
2. 설정 확인 방법
값이 정상적으로 변경되었는지 확인하려면 다음 명령어를 사용하세요.
sql
SHOW RESOURCE GROUPS;
출력 결과의 spill_mem_limit_threshold 컬럼 값이 `1`로 되어 있다면 성공적으로 초기화된 것입니다.
* 참고 사항*
* *`default_wg`*의 경우 StarRocks의 기본 리소스 그룹이며, 별도의 설정을 하지 않았을 때 이 값의 기본 사양은 항상 `1`입니다.
* 만약 자동 Spill 기능을 완전히 끄고 싶다면 시스템 변수인 `spill_mode`를 `shutdown`으로 설정하는 방법도 있지만, 리소스 그룹 설정만 초기화하려면 위의 ALTER 명령어가 가장 정확합니다.
References
• administration/management/resource_management/resource_group.md
• sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md
• administration/management/resource_management/spill_to_disk.md
References
• administration/management/resource_management/resource_group.md
• administration/management/BE_configuration.md
• faq/resource_isolation_faq.mdRonJay
07/20/2026, 8:13 AMRocky
07/20/2026, 8:13 AMmem_limit (BE 전체 메모리 제한)
가장 근본적인 원인은 mem_limit 설정입니다.
* 기본값: 90%
* BE 프로세스가 사용할 수 있는 총 메모리 상한선인 `mem_limit`은 별도로 고정값(예: 100G)을 주지 않으면 *서버(또는 Pod) 전체 메모리의 90%*로 자동 계산됩니다.
* 따라서 Pod 메모리를 증설하면 BE가 인식하는 mem_limit 자체가 커지게 됩니다.
2. storage_page_cache_limit (Page Cache)
스캔 성능 향상을 위해 사용되는 Page Cache는 `mem_limit`에 비례하여 설정됩니다.
* 기본값: 보통 전체 메모리의 20% 내외 (버전에 따라 상세 비율은 다를 수 있음)
* 이 설정이 백분율이나 자동 계산 방식으로 작동하기 때문에, 부모인 `mem_limit`이 늘어나면 자식인 Page Cache 용량도 함께 늘어납니다.
3. datacache_mem_size (Data Cache / Block Cache)
Data Lake나 Shared-data 환경에서 사용되는 Data Cache 역시 비슷합니다.
* 설정 방식: `be.conf`에서 `datacache_mem_size`를 `10%`와 같이 백분율로 설정할 수 있습니다.
* 별도로 설정하지 않았더라도 시스템이 가용한 메모리 상황에 맞춰 유동적으로 캐시 크기를 할당하도록 되어 있습니다.
4. 기타 연동되는 메트릭
Page Cache 외에도 다음과 같은 지표들이 전체 메모리 크기에 따라 함께 늘어났을 가능성이 큽니다.
* metadata_cache_memory_limit_percent: 메타데이터 캐시 상한선 (기본 30%)
* load_process_max_memory_limit_percent: 데이터 적재(Load)에 사용되는 메모리 (기본 30%)
──────────
확인 방법
현재 어떤 비율로 설정되어 있는지 보려면 BE의 구성 정보를 조회해 보세요.
sql
-- 캐시 관련 설정값 확인
ADMIN SHOW CONFIG LIKE '%cache%';
-- 전체 메모리 제한 확인
ADMIN SHOW CONFIG LIKE 'mem_limit';
요약
Pod 메모리를 늘리면 mem_limit (90%) → Page Cache (20%) / Data Cache (%) 순서로 연쇄적인 증설이 일어납니다. 이는 시스템이 늘어난 자원을 최대한 활용하여 쿼리 성능을 높이려는 의도된 동작입니다. 만약 캐시가 너무 커지는 것을 막고 싶다면 `be.conf`에서 해당 항목을 고정된 용량(예: VALUE="20G")으로 명시하면 됩니다.
References
• administration/management/BE_configuration.md
• administration/management/resource_management/Memory_management.md
• data_source/data_cache.md
References
• data_source/data_cache.md
• administration/management/BE_configuration.md
• administration/management/monitoring/metrics.md
• using_starrocks/caching/block_cache.mdRonJay
07/20/2026, 10:35 AMRocky
07/20/2026, 10:35 AMSHOW FRONTLENDS; 명령어로 `IsLeader`가 `true`인 FE의 IP로 직접 접속하여 확인하세요.
2. enable_profile 설정 미비
기본적으로 StarRocks는 성능 오버헤드를 줄이기 위해 모든 쿼리의 프로파일을 생성하지 않습니다.
* 원인: enable_profile 변수가 `false`(기본값)로 되어 있으면 상세 프로파일이 생성되지 않습니다.
* 해결: 쿼리 실행 전에 아래 명령어를 실행해야 합니다.
sql
SET enable_profile = true;
-- 또는 시스템 전체 적용 (권장하지 않음, 부하 주의)
SET GLOBAL enable_profile = true;
3. 프로파일 보관 개수 초과 (기본 100개)
FE는 메모리 관리를 위해 최근 실행된 *최대 100개*의 프로파일만 유지합니다.
* 원인: `enable_profile`이 켜진 상태에서 대량의 쿼리가 실행되면, 찾으려는 이전 쿼리의 프로파일이 메모리에서 밀려나 삭제됩니다.
* 참고: 이 개수는 FE 설정 파라미터(profile_info_reserved_max_num, 기본값 100)에 의해 결정됩니다.
4. FE 재시작
* 원인: 프로파일 정보는 FE의 *메모리*에 저장됩니다. 만약 FE가 재시작되었다면 기존에 실행되었던 모든 쿼리의 프로파일 정보는 초기화됩니다.
5. 아직 실행 중인 쿼리
* 원인: 쿼리가 종료되지 않고 실행 중인 경우, 최종 프로파일이 아직 FE로 보고되지 않아 "Not found"가 뜰 수 있습니다. (단, 3.1 버전 이상에서 Runtime Profile 기능이 켜져 있다면 중간 과정 확인은 가능합니다.)
──────────
팁: SQL로 직접 확인하기
UI에서 보이지 않는다면 SQL 클라이언트에서 직접 조회를 시도해 보세요.
sql
-- 1. 최근 프로파일 리스트 확인
SHOW PROFILELIST;
-- 2. 특정 Query ID의 프로파일 가져오기
SELECT get_query_profile('쿼리_ID_값');
만약 특정 시간 이상의 느린 쿼리만 자동으로 수집하고 싶다면 big_query_profile_threshold = '10s' (10초 이상 쿼리만 수집) 설정을 활용하는 것이 운영 방식을 권장합니다.
References
• administration/management/FE_configuration.md
• administration/management/logs.mdRonJay
07/22/2026, 10:24 AMRocky
07/22/2026, 10:24 AMbe.conf 파일을 수정하거나 ADMIN SET CONFIG 명령을 사용할 수 있습니다.
1. 전체 비활성화 (가장 확실한 방법)
Data Cache 기능 자체를 완전히 끄려면 datacache_enable 설정을 `false`로 변경합니다. 이 설정은 메모리(Page Cache 영역)와 디스크(Block Cache 영역) 캐시를 모두 비활성화합니다.
* 설정 위치: be.conf
* 설정 값:
properties
datacache_enable = false
(참고: 이 설정은 BE 재시작이 필요할 수 있습니다.)
──────────
2. 메모리 및 디스크 캐시 개별 비활성화
전체 기능을 끄지 않고 각각의 크기(Quota)를 0으로 만들어 사용하지 않게 설정할 수도 있습니다. 이 방법은 실행 중인 클러스터에서 즉시 적용할 때 유용합니다.
(1) Data Cache 메모리 사용 안 함
Data Cache에서 메모리 점유를 막으려면 `datacache_mem_size`를 `0`으로 설정합니다.
sql
ADMIN SET CONFIG ("datacache_mem_size" = "0");
(2) Data Cache 디스크 사용 안 함
디스크 캐시 용량을 `0`으로 설정하여 디스크 쓰기를 막습니다.
sql
ADMIN SET CONFIG ("datacache_disk_size" = "0");
──────────
3. 추가적인 세부 옵션 (버전에 따라 상이)
일부 환경이나 버전에 따라 아래 옵션을 추가로 확인할 수 있습니다.
* Block Cache(디스크 캐시) 비활성화:
properties
block_cache_enable = false
* Storage Page Cache(내부 테이블용 메모리 캐시) 비활성화:
데이터 레이크 캐시 외에 일반적인 테이블의 Page Cache도 끄고 싶다면 아래 옵션을 사용합니다.
properties
disable_storage_page_cache = true
설정 확인 방법
설정이 정상적으로 적용되었는지 확인하려면 SQL 클라이언트에서 다음 명령을 실행하세요.
sql
SHOW BACKENDS\G
-- 결과 중 DataCacheMetrics 항목의 Status가 Disabled이거나
-- DiskUsage, MemUsage의 할당량(Quota)이 0B/0B인지 확인합니다.
주의사항:
• Shared-data(Cloud-native) 모드나 데이터 레이크(S3, HDFS 등) 조회 시 캐시를 끄면 쿼리 성능이 크게 저하될 수 있습니다.
• `be.conf`를 직접 수정하는 경우 반드시 모든 BE 노드에 동일하게 적용하고 재시작해야 합니다.
References
• data_source/data_cache.md
• using_starrocks/caching/block_cache.md
• administration/management/BE_configuration.md
References
• using_starrocks/caching/block_cache.md
• data_source/data_cache.md
• data_source/data_cache_troubleshooting.md
• administration/management/BE_configuration.mdRonJay
07/22/2026, 10:37 AMRocky
07/22/2026, 10:38 AMSHOW PROC '/compute_nodes' 또는 SHOW COMPUTE NODES 명령을 실행했을 때 `MemUsedPct`나 기타 지표가 보이지 않거나 `0`으로 표시되는 이유는 크게 몇 가지로 나뉩니다.
1. StarRocks 버전 확인
`MemUsedPct`와 CpuUsedPct 지표는 *StarRocks 3.0 버전 이상*에서 본격적으로 SHOW PROC 결과에 포함되었습니다.
* 만약 2.x 버전 이하를 사용 중이라면 해당 컬럼 자체가 없거나 데이터가 올바르게 수집되지 않을 수 있습니다.
* `SHOW PROC '/frontends'`를 통해 현재 사용 중인 FE/BE 버전을 먼저 확인해 보세요.
2. 하트비트(Heartbeat) 및 통신 상태 확인
FE는 주기적으로 CN(Compute Node)이나 BE에 하트비트를 보내 상태 정보를 수집합니다.
* Alive 상태: Alive 컬럼이 `false`라면 해당 노드가 중단되었거나 FE와 연결이 끊긴 상태이므로 지표가 업데이트되지 않습니다.
* LastHeartbeat: LastHeartbeat 시간이 현재 시간과 가깝지 않다면 통신 지연이나 네트워크 문제가 있는 것입니다.
* 포트 개방 확인: FE와 CN 사이의 *Heartbeat 포트(기본 9050)*와 *bRPC 포트(기본 8060)*가 방화벽 등으로 막혀 있는지 확인해야 합니다.
3. 노드 부팅 후 대기 시간
노드가 방금 시작되었다면 첫 번째 지표가 보고되기까지 *약 10~20초 정도의 하트비트 주기*가 필요합니다. 부팅 직후에는 정보가 N/A 또는 0으로 보일 수 있으니 잠시 후 다시 시도해 보세요.
4. 컨테이너(Docker/K8s) 환경의 제약
StarRocks는 리눅스의 cgroups 정보를 읽어 메모리 사용량을 계산합니다.
* 특정 컨테이너 환경에서 자원 할당 정보(/sys/fs/cgroup/...)에 접근할 권한이 없거나, 구버전 Docker를 사용하는 경우 메모리 사용률 계산에 실패하여 `0`으로 표시될 수 있습니다.
* CN 노드의 로그(<http://cn.INFO|cn.INFO> 또는 cn.WARNING)에서 "failed to get memory info"와 같은 에러가 있는지 확인이 필요합니다.
5. 해결 방법 요약
1. 세로 모드로 보기: 컬럼이 너무 많아 잘려 보일 수 있으므로 SHOW COMPUTE NODES\G (MySQL 클라이언트 기준)를 입력하여 모든 필드를 하나씩 확인하세요.
2. 권한 확인: SYSTEM-level OPERATE 권한이나 cluster_admin 역할이 있는지 확인하세요.
3. 로그 확인: FE 로그(fe.log)에서 해당 노드로부터 리포트를 받는 과정에 에러가 있는지 체크하세요.
4. 최신 버전 권장: 가급적 3.x 이상의 최신 마이너 버전을 유지하는 것이 지표 정확도 측면에서 유리합니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• administration/management/monitoring/metrics.md
References
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.mdRonJay
07/23/2026, 1:13 AMRocky
07/23/2026, 1:13 AMenable_query_queue_v2 = true)되어 있으며, 기존의 단순 임계치 방식에서 발전한 *슬롯 기반(Slot-based) 스케줄러*를 사용합니다.
메모리 헤비(Heavy) 쿼리와 CPU 헤비 쿼리가 혼합된 환경에서 자원을 효율적으로 배분하기 위한 가이드라인을 정리해 드립니다.
──────────
1. 핵심 개념: 슬롯 기반 스케줄링 (Slot-based Scheduling)
Query Queue v2는 쿼리가 필요로 하는 자원을 '슬롯' 단위로 계산하여 관리합니다. Leader FE가 클러스터 전체의 슬롯 상황을 관리하므로, 여러 FE를 통한 동시 접속 시에도 전역적인 큐 제어가 가능합니다.
2. 시나리오별 자원 그룹(Resource Group) 설정 가이드
가장 효과적인 방법은 *쿼리 성격에 따라 자원 그룹을 분리*하고, 각 그룹에 맞는 제약 조건을 거는 것입니다.
(1) CPU 헤비 쿼리 그룹 (예: 복잡한 연산, 대량 조인)
CPU 연산량이 많은 쿼리는 자원을 독점하지 않도록 `cpu_weight`와 `concurrency_limit`을 조절합니다.
sql
CREATE RESOURCE GROUP cpu_intensive_rg
TO (user='analytics_user')
WITH (
"cpu_weight" = "10", -- 다른 그룹 대비 CPU 우선순위 설정
"concurrency_limit" = "20", -- 동시 실행 쿼리 수를 제한하여 CPU 오버헤드 방지
"max_cpu_cores" = "16" -- 개별 BE에서 사용할 최대 코어 수 제한
);
(2) 메모리 헤비 쿼리 그룹 (예: 대량 데이터 정렬, 대형 해시 테이블)
메모리 사용량이 큰 쿼리는 시스템 전체의 OOM(Out of Memory)을 유발할 수 있으므로 `mem_limit`과 spill 설정을 강화합니다.
sql
CREATE RESOURCE GROUP mem_intensive_rg
TO (role='data_scientist')
WITH (
"mem_limit" = "40%", -- 이 그룹이 전체 메모리의 40% 이상 쓰지 못하게 제한
"big_query_mem_limit" = "10GB", -- 개별 쿼리가 사용할 수 있는 최대 메모리 캡 설정
"spill_mem_limit_threshold" = "0.8", -- 메모리의 80% 사용 시 디스크 스필링(Spilling) 유도
"concurrency_limit" = "5" -- 메모리 폭주 방지를 위해 동시 실행 수를 낮게 유지
);
──────────
3. 효율적 동시 처리를 위한 전역 최적화 설정
① 동기적 동시성 조절 (Dynamic DOP)
Query Queue v2는 시스템 부하에 따라 쿼리의 병렬도(pipeline_dop)를 동적으로 조절합니다. 부하가 높을 때 새 쿼리의 병렬도를 낮춰 자원 경합을 줄입니다.
sql
-- 실행 중인 드라이버 수가 High Water를 넘으면 병렬도를 낮춤
SET GLOBAL query_queue_driver_high_water = 0; -- 0은 자동 계산 (avg_be_cpu_cores * 16)
SET GLOBAL query_queue_driver_low_water = 0; -- 0은 자동 계산 (avg_be_cpu_cores * 8)
② 큐잉 임계치 설정 (Global Thresholds)
특정 그룹의 설정과 별개로 BE 노드 전체의 자원이 위험 수준에 도달하면 무조건 큐에 대기시킵니다.
sql
SET GLOBAL query_queue_mem_used_pct_limit = 0.9; -- BE 메모리 90% 도달 시 큐잉
SET GLOBAL query_queue_cpu_used_permille_limit = 800; -- CPU 사용률 80% 도달 시 큐잉
──────────
4. 권장 운영 가이드라인 (Best Practices)
1. 분류기(Classifier) 활용: 쿼리 타입(query_type in ('select')), 사용자, IP 주소 등을 통해 자동으로 쿼리를 적절한 그룹으로 보냅니다.
2. 대기 시간 및 큐 길이 제한: 무한정 대기하지 않도록 제한을 둡니다.
* query_queue_max_queued_queries = 100 (최대 대기 쿼리 수)
* query_queue_pending_timeout_second = 300 (5분 이상 대기 시 실패 처리)
3. 모니터링: 쿼리가 대기 중인지 확인하려면 `SHOW PROCESSLIST`의 IsPending 컬럼을 확인하세요.
sql
SHOW PROCESSLIST; -- IsPending이 true이면 현재 큐에서 대기 중인 쿼리입니다.
4. 우선순위 관리: default_wg 그룹의 설정을 `ALTER RESOURCE GROUP`으로 조정하여, 그룹에 속하지 않은 일반 쿼리가 자원을 다 써버리지 않도록 주의하세요.
이 설정을 통해 CPU 헤비 쿼리는 처리 속도가 다소 늦어지더라도 시스템을 멈추지 않게 하고, 메모리 헤비 쿼리는 적은 수만 실행되어 안정성을 확보할 수 있습니다.
References
• administration/management/resource_management/query_queues.md
• administration/management/resource_management/resource_group.md
• administration/management/FE_configuration.md
• administration/management/monitor_manage_big_queries.md
References
• administration/management/resource_management/query_queues.md
• administration/management/monitor_manage_big_queries.mdRonJay
07/24/2026, 2:04 AMRocky
07/24/2026, 2:05 AMALTER SYSTEM DROP COMPUTE NODE 명령어로도 삭제되지 않고 목록에 남아있다면, 다음 단계별 조치 방법을 확인해 보시기 바랍니다.
1. 정확한 주소 확인 및 기본 명령어 실행
가장 먼저 SHOW PROC '/compute_nodes'; 명령어를 통해 해당 CN의 *정확한 IP와 HeartbeatPort*를 확인하세요. 간혹 호스트네임과 IP 혼용으로 인해 명령어가 먹히지 않는 경우가 있습니다.
sql
-- SHOW PROC '/compute_nodes' 결과에서 확인된 IP와 포트를 사용
ALTER SYSTEM DROP COMPUTE NODE "IP:PORT";
예: ALTER SYSTEM DROP COMPUTE NODE "10.0.0.1:9050";
──────────
2. Warehouse(웨어하우스) 환경 확인 (중요)
StarRocks 3.x/4.x 버전부터는 Warehouse 개념이 도입되었습니다. CN이 특정 웨어하우스에 속해 있는 경우, 일반적인 DROP 명령이 아닌 웨어하우스 관리 명령이 필요할 수 있습니다.
* SHOW WAREHOUSES; 명령어로 현재 웨어하우스 목록을 확인합니다.
* 만약 특정 웨어하우스에 CN이 묶여 있다면, 해당 웨어하우스를 정지하거나 노드를 수동으로 제거해야 할 수 있습니다. (주로 Cloud-native/Shared-data 모드에서 발생)
──────────
3. 상태(StatusCode) 및 하트비트 확인
SHOW COMPUTE NODES 또는 SHOW PROC '/compute_nodes' 결과에서 해당 CN의 *StatusCode*를 확인하세요.
* SHUTDOWN/DISCONNECTED: 이미 종료 프로세스 중이지만 FE 메타데이터에서 제거되지 않은 경우입니다.
* Alive: false 인 경우에도 목록에 남아있다면, FE가 해당 노드의 삭제 로그를 제대로 처리하지 못한 것일 수 있습니다. 이 경우 FE Leader 노드를 재시작하면 메타데이터가 동기화되며 사라지는 경우가 많습니다.
──────────
4. Kubernetes(K8s) 환경인 경우
만약 StarRocks Operator를 통해 K8s 환경에서 운영 중이라면, SQL 명령어로 CN을 지워도 *Operator가 다시 노드를 생성하거나 상태를 유지*하려고 시도할 수 있습니다.
* 이 경우 SQL 명령어가 아니라 StarRocksComputeNode(CN) 커스텀 리소스의 replicas 수를 줄이거나, 특정 파드(Pod)를 삭제하는 방식으로 대응해야 합니다.
──────────
5. 강제 삭제 시도 (Troubleshooting)
위 방법으로도 해결되지 않을 때 시도해 볼 수 있는 방법입니다.
1. 명령어 재시도: `ALTER SYSTEM DROP COMPUTE NODE`는 동기 작업이므로, 네트워크 일시 오류로 실패했을 수 있습니다. 다시 실행해 보세요.
2. FE 로그 확인: FE의 fe.log 또는 `fe.warn.log`를 확인하여 DROP COMPUTE NODE 실행 시 발생하는 에러 메시지를 찾습니다. (예: "Node not found", "Tablet remaining" 등)
3. FE 리더 전환: 클러스터 메타데이터 관리 이슈일 경우, ALTER SYSTEM RESTART FE 등을 통해 FE 리더를 교체하면 해결되기도 합니다.
참고: CN은 BE와 달리 데이터를 저장하지 않으므로 DECOMMISSION 과정(데이터 이관)이 필요 없습니다. DROP 명령 시 즉시 삭제되는 것이 정상입니다. 만약 계속 남아있다면 FE 메타데이터상의 불일치일 가능성이 높습니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/ALTER_SYSTEM.md
• administration/management/Scale_up_down.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md
References
• administration/management/Scale_up_down.md
• sql-reference/sql-statements/cluster-management/nodes_processes/ALTER_SYSTEM.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md
• administration/stargo.md
References
• administration/stargo.md
• administration/management/Scale_up_down.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.mdRonJay
07/24/2026, 3:57 AMRocky
07/24/2026, 3:57 AMALTER SYSTEM 명령어를 사용하는 것입니다. 이 명령은 Leader FE에서 비동기적으로 체크포인트를 수행하여 새로운 이미지 파일을 생성하도록 트리거합니다.
sql
ALTER SYSTEM CREATE IMAGE;
* 동작 원리: Leader FE가 현재까지의 EditLog를 모두 읽어 하나의 image.<version> 파일로 저장합니다.
* 확인 방법: 명령 실행 후 FE 로그(fe.log)에서 다음과 같은 메시지를 확인하세요.
* 시작: triggering a new checkpoint manually...
* 완료: finished save image...
* 파일 위치: FE 설치 경로의 meta/image/ 디렉토리에 새로운 image.xxxx 파일이 생성됩니다.
──────────
2. 관련 설정값 조절 (자동 주기 조정)
수동 실행 외에, 너무 자주 또는 너무 가끔 이미지가 생성된다면 다음 FE 설정값(fe.conf)을 조정하여 자동 생성 주기를 관리할 수 있습니다.
* edit_log_roll_num: EditLog 파일 하나에 기록되는 로그 수입니다. (기본값: 50000) 이 수치에 도달하면 새 로그 파일로 롤링됩니다.
* checkpoint_number: 마지막 이미지 생성 이후 누적된 로그 수가 이 설정값에 도달하면 자동으로 체크포인트(이미지 생성)를 수행합니다. (기본값: 50000)
설정값 확인 및 임시 변경:
sql
ADMIN SHOW FRONTEND CONFIG LIKE 'checkpoint_number';
-- 필요한 경우 동적으로 변경 (버전에 따라 다를 수 있음)
ADMIN SET FRONTEND CONFIG ("checkpoint_number" = "100000");
──────────
3. 주의사항
* Leader FE에서 실행: 이미지 생성 작업은 Leader FE의 자원(CPU/Memory)을 사용하므로, 메타데이터가 매우 큰 환경에서는 운영 시간 외에 수행하는 것이 좋습니다.
* 디스크 공간: 새로운 이미지 파일이 생성될 때 기존 이미지와 함께 일시적으로 디스크를 점유하므로 meta 디렉토리의 여유 공간을 확인하세요.
* 버전 관리: StarRocks는 기본적으로 최근 몇 개의 이미지 파일과 EditLog를 유지하며 오래된 파일은 자동으로 삭제합니다.
만약 ALTER SYSTEM CREATE IMAGE 실행 후에도 로그에 에러가 발생하며 이미지가 만들어지지 않는다면, `fe.log`에서 Exception when generate new image file 문구를 찾아 상세 원인을 파악해야 합니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/ALTER_SYSTEM.md
• administration/management/monitoring/alert.md
• administration/management/FE_configuration.md
References
• administration/management/compaction.md
• sql-reference/sql-statements/cluster-management/nodes_processes/ALTER_SYSTEM.md
• administration/management/monitoring/alert.md
• knowledge/admin_and_operation/shared_data_compaction.mdRonJay
07/24/2026, 4:02 AMRocky
07/24/2026, 4:02 AMsql
SHOW PROCESSLIST;
* Id: Connection ID (이 번호를 Kill 명령어에 사용합니다).
* User: 쿼리를 실행한 사용자.
* Time: 쿼리가 실행된 시간(초).
* Info: 실행 중인 SQL 문장.
만약 특정 데이터베이스나 사용자 쿼리만 보고 싶다면 다음과 같이 필터링할 수 있습니다.
sql
-- 실행 시간이 60초 이상인 쿼리만 확인
SELECT * FROM information_schema.exec_queries WHERE duration > 60;
──────────
2. 쿼리 중단 (Kill) 명령어
확인한 ID를 사용하여 쿼리를 종료합니다.
(1) 특정 쿼리만 종료 (추천)
세션(연결)은 유지하고 현재 실행 중인 쿼리만 즉시 중단합니다.
sql
KILL QUERY <connection_id>;
예: KILL QUERY 12345;
(2) 세션 자체를 종료
쿼리를 포함하여 해당 사용자의 *데이터베이스 연결(세션) 자체*를 강제로 끊습니다.
sql
KILL <connection_id>;
예: KILL 12345;
──────────
3. 대량 적재(Load) 작업 중단
일반 SQL 쿼리가 아니라 `ROUTINE LOAD`나 INSERT INTO 같은 적재 작업을 중단하려면 별도의 명령어를 사용해야 합니다.
* INSERT INTO 쿼리: 위와 동일하게 KILL 명령어를 사용합니다.
* Routine Load (Kafka 등):
sql
STOP ROUTINE LOAD FOR <job_name>;
* Stream Load / Broker Load:
sql
CANCEL LOAD FROM <db_name> WHERE LABEL = "label_name";
주의사항
* 권한: 본인의 쿼리는 직접 Kill 할 수 있지만, 다른 사용자의 쿼리를 Kill 하려면 SUPER 권한(Admin)이 필요합니다.
* 반영 시간: KILL 명령어를 입력하면 즉시 중단 신호를 보내지만, 복잡한 연산이나 자원 해제 과정으로 인해 실제 목록에서 사라지기까지 수 초 정도 시간이 걸릴 수 있습니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
• sql-reference/sql-statements/data-manipulation/CANCEL_LOAD.mdRonJay
07/24/2026, 4:48 AMRocky
07/24/2026, 4:48 AMSHOW PROCESSLIST; 또는 *`SELECT * FROM information_schema.exec_queries;`*
* `State`가 `Pending`이라면: 자원 부족으로 인한 큐잉(Queueing)입니다.
* `State`가 `Running`인데 `Time`만 올라간다면: 특정 노드에서 연산이 막혔거나 데이터 스큐(Skew)가 발생한 것입니다.
2. 리소스 그룹(Resource Group) 설정 확인
규모가 큰 클러스터는 보통 여러 사용자가 공유하므로 *Resource Group(Workload Group)*이 설정되어 있을 확률이 높습니다.
* SHOW RESOURCE GROUPS;
* 본인이 속한 그룹의 `concurrency_limit`에 걸려 쿼리가 대기 중인지 확인하세요.
* 작은 클러스터에서는 설정이 없어서 잘 돌다가, 큰 클러스터에서는 제한에 걸리는 경우가 빈번합니다.
3. Query Profile 분석 (가장 확실한 방법)
쿼리가 실행 중이라면 StarRocks의 상세 프로파일을 통해 어떤 연산자(Operator)에서 시간이 끌리는지 확인해야 합니다.
sql
SET enable_profile = true;
-- 쿼리 실행 (대기 중이라도 어느 정도 시간이 지나면 중단 후 확인 가능)
-- 그 다음 가장 최근 쿼리의 프로파일 ID 확인
SELECT LAST_QUERY_ID();
-- 상세 프로파일 확인 (StarRocks Dashboard가 있다면 웹 UI에서 보는 것이 훨씬 편합니다)
GET_QUERY_PROFILE('쿼리ID');
* 확인 포인트: 특정 BE(Backend) 노드만 CPU 사용량이 높거나, 특정 조인(Join) 단계에서 `PendingTime`이 긴지 확인합니다.
4. 쿼리 실행 계획(Explain Plan) 비교
클러스터 규모가 달라지면 CBO(Cost-based Optimizer)가 생성하는 실행 계획이 완전히 달라질 수 있습니다.
* EXPLAIN <쿼리문>; 명령어로 두 클러스터의 실행 계획을 비교하세요.
* 체크리스트:
* Join 방식: 작은 클러스터는 BROADCAST 조인을 썼는데, 큰 클러스터에서 데이터 통계를 기반으로 SHUFFLE 조인을 선택하면서 네트워크 부하가 커졌을 수 있습니다.
* Tablet 스캔: 큰 클러스터로 오면서 데이터 분산(Bucket) 수가 너무 많아져, 스캔해야 할 태블릿 수가 급증하여 메타데이터 처리에 대기가 생길 수 있습니다.
5. 메타데이터 및 잠금(Lock) 확인
쿼리가 아예 시작되지 않는다면 FE(Frontend)의 락 경합일 수 있습니다.
* SHOW PROC '/locks';
* 다른 대규모 적재(Load) 작업이나 DDL 작업이 진행 중이어서 테이블에 락이 걸려 쿼리가 대기 중인지 확인합니다.
6. 노드 상태 및 네트워크 확인
규모가 큰 클러스터일수록 노드 하나가 느려지면 전체 쿼리가 해당 노드를 기다리느라 멈추는 'Straggler' 현상이 발생하기 쉽습니다.
* SHOW BACKENDS; 명령어로 `Alive`가 `false`인 노드가 있는지, 혹은 특정 노드의 `MemoryUsed`가 꽉 찼는지 확인하세요.
──────────
요약 가이드:
1. `SHOW PROCESSLIST`로 큐잉 여부 확인.
2. `EXPLAIN`으로 두 클러스터 간 Join 방식 차이 확인.
3. SET enable_profile = true 후 프로파일을 통해 병목 노드/연산자 파악.
만약 프로파일 상에서 특정 노드에만 데이터가 몰려 있다면(Data Skew), 테이블의 DISTRIBUTED BY 키가 대규모 데이터 세트에서 적절하지 않게 설정된 것일 수 있습니다.
References
• administration/management/resource_management/resource_group.md
• administration/management/resource_management/workload_group.md
• administration/query_profile_overview.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
References
• administration/query_profile_overview.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
• administration/management/resource_management/resource_group.md
• administration/management/resource_management/workload_group.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
• administration/query_profile_overview.mdRocky
07/24/2026, 4:48 AMRocky
07/24/2026, 4:48 AMRocky
07/24/2026, 4:48 AMRocky
07/24/2026, 4:48 AMRonJay
07/24/2026, 4:54 AMRocky
07/24/2026, 4:54 AMenable_scan_datacache 세션 변수를 쿼리 힌트(Hint) 형태로 사용하거나, 해당 쿼리 실행 직전에 세션 설정을 변경하면 됩니다.
StarRocks의 Data Cache는 주로 내장 스토리지(Shared-data 모드)나 외부 테이블(HDFS, S3 등) 스캔 시 성능을 높이기 위해 사용됩니다.
방법 1: 쿼리 힌트(Hint) 사용 (가장 추천)
쿼리 문장 안에 직접 설정을 삽입하여 해당 쿼리 하나에만 적용하는 방식입니다. 별도의 세션 복구가 필요 없어 가장 깔끔합니다.
sql
SELECT /*+ SET_VAR(enable_scan_datacache = false) */
*
FROM your_external_table
WHERE id = 100;
방법 2: 세션 변수 일시 변경
쿼리를 실행하기 전에 세션 수준에서 캐시를 끄고, 실행 후 다시 켜는 방법입니다.
sql
-- 1. 캐시 비활성화
SET enable_scan_datacache = false;
-- 2. 쿼리 실행
SELECT * FROM your_external_table ...;
-- 3. 다시 활성화 (필요 시)
SET enable_scan_datacache = true;
참고 사항
* enable_scan_datacache: 기본값은 보통 `true`입니다. 이를 `false`로 설정하면 해당 쿼리는 BE(Backend) 노드의 로컬 디스크에 저장된 캐시 데이터를 읽지 않고, 원본 스토리지(S3, HDFS 등)에서 직접 데이터를 가져옵니다.
* 적용 대상: 이 설정은 내장 테이블(Shared-data 아키텍처) 및 모든 외부 테이블(Hive, Iceberg, Hudi, Delta Lake 등) 스캔 시에 적용됩니다.
* 용도: 캐시 오염을 방지하고 싶을 때(예: 대량의 일회성 배치 쿼리 실행 시) 또는 캐시가 아닌 원본 데이터와의 성능 비교 테스트를 할 때 유용합니다.
References
• data_source/Data_cache.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SET_VARIABLE.md
• administration/management/BE_configuration.mdRonJay
07/27/2026, 2:04 AMRocky
07/27/2026, 2:04 AMSHOW PROC '/compute_nodes'; 명령어에서 특정 CN 노드의 `DataCacheMetrics`가 *`NA`*로 표시되면서 메모리 점유율이 높은 현상은 다음과 같은 원인일 가능성이 매우 높습니다.
1. `DataCacheMetrics`가 `NA`인 이유
`NA`는 해당 CN 노드에서 *Data Cache 기능이 활성화되지 않았거나, 초기화에 실패했음*을 의미합니다.
* 설정 확인: 해당 노드의 cn.conf 파일에 enable_datacache = true 설정이 빠져 있거나, 캐시 경로(datacache_path)에 문제가 있을 수 있습니다.
* 초기화 실패: 디스크 공간 부족이나 권한 문제로 Data Cache가 시작되지 못하면 FE(Frontend)는 해당 노드로부터 메트릭을 받을 수 없어 `NA`로 표시합니다.
2. 메모리 점유가 높은 원인 (버그 가능성)
실제 쿼리를 많이 수행하지 않음에도 특정 CN 노드만 메모리를 과도하게 점유하고 있다면, StarRocks v3.1/v3.2 대 버전에서 보고된 Data Cache 메타데이터 메모리 누수(Memory Leak) 문제일 가능성이 큽니다.
* 현상: Data Cache가 정상 작동하지 않거나 비정상 종료된 상태에서도 fslib star cache meta 관련 모듈이 메모리를 해제하지 않고 계속 점유하는 경우가 있습니다.
* 확인 방법:
브라우저에서 해당 CN 노드의 MemTracker 페이지에 접속하여 어떤 모듈이 메모리를 쓰고 있는지 확인하세요.
http://<CN_IP>:<CN_HTTP_PORT>/mem_tracker
여기서 starlet_cache 또는 fslib 관련 항목의 current_consumption 수치가 높다면 이 버그에 해당합니다.
3. 해결 절차
1단계: 메모리 세부 정보 확인
실제로 어떤 모듈이 메모리를 점유하는지 쿼리로 확인합니다.
sql
-- CN 노드의 메모리 트래커 정보를 조회 (버전별로 경로가 다를 수 있음)
SHOW PROC '/mem_tracker';
2단계: Data Cache 메타데이터 정리 및 재시작 (권장)
알려진 버그(v3.1.8, v3.2.3 이하)에 해당한다면, 캐시 디렉토리의 메타데이터를 삭제하고 재시작해야 메모리가 완전히 복구됩니다.
1. 해당 CN 노드를 중지합니다.
2. `cn.conf`에 설정된 storage_root_path (또는 캐시 경로) 하위의 다음 디렉토리를 삭제합니다.
* 예: rm -rf ${storage_root_path}/starlet_cache/star_cache/meta
3. CN 노드를 다시 시작합니다.
3단계: 버전 업그레이드
이 문제는 v3.1.9 및 v3.2.4 이상의 패치 버전에서 해결되었습니다. 만약 하위 버전을 사용 중이라면 업그레이드를 권장합니다.
요약
`DataCacheMetrics`가 *`NA`*인 것이 메모리 상승의 직접적인 원인이라기보다, *Data Cache 모듈이 비정상적인 상태(초기화 실패 등)에 빠지면서 메모리만 점유하고 제어권을 상실한 상태*일 확률이 높습니다.
가장 빠른 해결책은 *CN 노드 중지 -> 캐시 meta 디렉토리 삭제 -> 재시작*입니다.
References
• using_starrocks/caching/block_cache.md
• data_source/data_cache_troubleshooting.md
• administration/management/resource_management/Memory_management.md
References
• administration/management/resource_management/Memory_management.md
• knowledge/trouble_shooting/fe_memory_problems.md
• using_starrocks/caching/block_cache.md
• faq/fe_mem_faq.mdRonJay
07/27/2026, 2:05 AMRocky
07/27/2026, 2:06 AMmem_tracker 간의 메모리 수치 차이*가 발생하는 상황은 매우 전형적인 *Data Cache(Block Cache) 모듈의 이상 상태*를 나타냅니다.
`NA`가 원인이라기보다, *Data Cache 모듈이 비정상적인 상태(Initialization Failure 또는 Crash)에 빠져서 메모리는 점유하고 있지만 메트릭 보고는 중단된 상태*일 가능성이 큽니다.
1. 왜 `mem_tracker`에서는 정상으로 보이나요?
StarRocks의 `mem_tracker`는 주로 쿼리 실행, 메타데이터 관리 등 StarRocks 내부 로직에 의해 할당된 메모리를 추적합니다. 반면, Data Cache(특히 Block Cache) 모듈은 다음과 같은 이유로 `mem_tracker`에서 누락되거나 다르게 보일 수 있습니다.
* 메타데이터 메모리 점유: Data Cache는 디스크에 저장된 데이터의 인덱싱을 위해 상당량의 메모리를 메타데이터로 사용합니다. 특정 버전(v3.1.8, v3.2.3 이하)에서는 이 메타데이터가 `mem_tracker`에 정상적으로 잡히지 않으면서 실제 OS 메모리만 점유하는 버그가 알려져 있습니다.
* TCMalloc 캐시: TCMalloc이 애플리케이션으로부터 메모리를 반환받았지만 OS에 즉시 돌려주지 않고 들고 있는 경우입니다. 이 경우 Prometheus(Resident Memory)는 높게 나오지만 `mem_tracker`는 낮게 보입니다.
* 초기화 실패 상태의 점유: Data Cache가 시작될 때 메모리를 미리 할당(Pre-allocation)하거나 메타데이터를 로드하다가 중단된 경우, 해당 메모리가 "사용 중"인 것으로 OS에 인식되지만 모듈 자체는 작동하지 않아 `NA`로 표시될 수 있습니다.
2. `DataCacheMetrics: NA`가 의미하는 것
`NA`는 FE(Frontend)가 해당 CN으로부터 캐시 상태 데이터를 받지 못했다는 뜻입니다.
* 해당 노드의 Data Cache 서비스가 활성화되지 않았거나,
* 캐시 경로(Disk)에 문제가 있어 서비스가 로딩 중 멈췄거나,
* 메타데이터 오염으로 인해 *모듈이 비정상 종료*된 상태입니다.
3. 해결 절차 (Action Plan)
Step 1: CN 노드의 로그 확인 (가장 중요)
해당 CN 노드에 접속하여 log/be.INFO 또는 log/be.out 파일을 확인하세요.
* grep -i "cache" <http://be.INFO|be.INFO> 명령어로 에러 메시지를 찾습니다.
* DataCache failed to initialize 또는 Block cache meta error 같은 메시지가 있다면 확실한 원인입니다.
Step 2: 캐시 메타데이터 삭제 및 재시작
문제가 되는 특정 노드에서만 발생한다면 캐시 데이터/메타데이터 오염일 가능성이 높습니다.
1. 해당 CN 노드를 중지합니다.
2. `cn.conf`에 설정된 캐시 디렉토리(보통 ${storage_root_path}/starlet_cache/) 하위의 *`meta` 디렉토리를 삭제*합니다.
bash
rm -rf /your/cache/path/starlet_cache/star_cache/meta
3. CN 노드를 다시 시작합니다.
Step 3: /memz 확인
Prometheus 지표와 `mem_tracker`의 차이를 더 정확히 보려면 CN 노드의 HTTP 인터페이스를 확인하세요.
* http://<CN_IP>:<HTTP_PORT>/memz
* 여기서 *`Total physical memory usage`*와 *`Bytes in use by application`*을 비교해 보세요. 만약 `page heap freelist`가 크다면 TCMalloc이 메모리를 잡고 있는 것이고, `fslib`이나 starlet 관련 수치가 크다면 캐시 모듈 문제입니다.
요약
해당 CN의 *Data Cache 모듈이 좀비 상태(Zombie state)*에 빠져 있을 가능성이 99%입니다. `NA`로 표시되는 노드는 현재 캐시 기능이 동작하지 않으면서 메모리만 낭비하고 있는 상태이므로, 위 절차에 따라 *캐시 메타데이터 삭제 후 재시작*하는 것이 가장 효과적인 조치입니다.
만약 StarRocks v3.1.x 또는 v3.2.x의 초기 버전을 사용 중이시라면, 이 현상은 알려진 메타데이터 메모리 누수 버그이므로 v3.1.9 또는 v3.2.4 이상으로 업데이트를 권장합니다.
References
• using_starrocks/caching/block_cache.md
• data_source/data_cache_observe.md
• administration/management/resource_management/Memory_management.md
References
• using_starrocks/caching/block_cache.md
• data_source/data_cache_observe.md
• data_source/data_cache.md
• administration/management/monitoring/metrics.mdRonJay
07/27/2026, 2:09 AMRocky
07/27/2026, 2:09 AMbash
# 해당 CN 노드의 프로세스를 중지합니다.
2. 문제가 되는 메타데이터 디렉토리 삭제
`cn.conf`에 설정된 캐시 경로(보통 storage_root_path 하위)에서 다음 폴더를 완전히 삭제합니다. 이 작업은 실제 캐시 데이터가 아닌 인덱스 정보만 삭제하므로 안전하며, 재시작 시 자동으로 재생성됩니다.
bash
rm -rf <데이터_캐시_경로>/starlet_cache/star_cache/meta
3. CN 노드 재시작
노드를 다시 실행하면 `DataCacheMetrics`가 `Normal`로 돌아오고, 메모리 점유율도 정상 범위(초기 상태)로 내려갈 것입니다.
4. 권장 사항
* 버전 업데이트: 이 문제는 v3.1.9 및 v3.2.4 이상 버전에서 수정되었습니다. 현재 사용 중인 버전이 낮다면 패치 버전 업그레이드를 강력히 권장합니다.
* 로그 확인: 재시작 후에도 계속 `NA`가 뜬다면, 해당 CN 노드의 log/be.INFO 파일에서 cache 또는 starlet 키워드로 검색하여 디스크 권한 문제나 설정 오류가 없는지 확인하시기 바랍니다.
References
• using_starrocks/caching/block_cache.md (Known issues: High memory usage 참고)
• data_source/data_cache_observe.md
• administration/management/resource_management/Memory_management.md
References
• administration/management/resource_management/Memory_management.md
• using_starrocks/caching/block_cache.md
• administration/management/monitoring/alert.md
• administration/management/monitoring/Monitor_and_Alert.md
• administration/management/BE_configuration.md
• deployment/sr_operator.mdRonJay
07/27/2026, 2:11 AMRocky
07/27/2026, 2:11 AMlog/ 디렉토리에서 <http://cn.INFO|cn.INFO> (또는 <http://be.INFO|be.INFO>) 파일을 확인합니다.
* 하트비트(Heartbeat) 확인:
FE와 CN 간의 기본 연결 상태를 확인합니다. 아래 키워드로 검색했을 때 주기적인 로그가 찍혀야 합니다.
bash
grep "heartbeat" log/cn.INFO | tail -n 20
* get heartbeat from FE 같은 메시지가 없거나 에러가 있다면 네트워크 또는 FE 주소 설정 문제입니다.
* 리포트(Report) 전송 확인:
CN은 자신의 상태(Tablet, Metrics 등)를 주기적으로 Master FE에 리포트합니다. 리포트 실패 시 보통 thrift 관련 에러가 발생합니다.
bash
grep -E "report|thrift|Master" log/cn.INFO | grep -i "fail"
* fail to report to Master FE 혹은 RPC error 등이 발견된다면 통신 상의 문제입니다.
* Data Cache 모듈 상태 확인:
`DataCacheMetrics`가 `NA`라면 캐시 모듈 자체의 초기화 실패를 의심해야 합니다.
bash
grep -iE "cache|starlet|block" log/cn.INFO | grep -i "fail"
* `BlockCache failed to init`이나 storage_root_path 관련 권한 에러가 있는지 확인하세요.
──────────
2. CN 로컬 API를 통한 자가 진단
FE를 거치지 않고 CN이 현재 자신의 캐시 상태를 어떻게 인식하는지 직접 확인할 수 있습니다.
* Data Cache 상세 상태 확인:
bash
curl http://<CN_IP>:<CN_HTTP_PORT>/api/datacache/stat
* 여기서 `block_cache_status`가 `NORMAL`이 아닌 다른 값으로 나오거나, 아예 응답이 없다면 CN 내부의 캐시 엔진이 멈춘 것입니다.
──────────
3. FE 로그 점검 (수신 측 확인)
CN에서 보낸 리포트를 FE가 거절하고 있을 수도 있습니다. *Master FE*의 `log/fe.log`를 확인하세요.
* CN 리포트 수신 로그:
bash
grep "backend report" log/fe.log | grep "<CN_IP>"
* 리포트를 받았지만 `diff`가 너무 커서 무시하거나, CN의 ID가 중복/불일치하여 거절하는 경우가 로그에 남습니다.
──────────
4. 정리 및 체크리스트
현재 증상(mempctused 0, datacachemetric na, cpuused 0%)은 *CN의 정보 보고(Report) 스레드가 아예 동작하지 않거나 차단된 상태*임을 강하게 시사합니다.
1. 네트워크: CN에서 FE의 `query_port`(기본 9030) 및 `rpc_port`(기본 9020)로 접근 가능한지 telnet 등으로 확인하세요.
2. 프로세스 상태: CN 프로세스가 떠 있더라도 내부의 특정 스레드가 교착 상태(Deadlock)에 빠졌을 수 있습니다. `log/cn.out`에 *Core Dump*나 *Stack Trace*가 찍혀 있지 않은지 확인하세요.
3. 임시 조치: 만약 로그에 특별한 통신 에러가 없는데 수치가 0이라면, 이전 답변에서 언급한 *캐시 메타데이터 디렉토리 삭제 후 재시작*이 가장 확실한 복구 방법입니다.
References
• administration/management/logs.md
• data_source/data_cache_observe.md
• administration/management/BE_configuration.md (Statistic report 섹션 참고)
References
• administration/management/logs.md
• sql-reference/information_schema/be_logs.md
• administration/management/BE_configuration.mdRonJay
07/27/2026, 4:51 AMRocky
07/27/2026, 4:51 AMpip_scan): StarRocks 내부 테이블(로컬 디스크 또는 Shared-data의 S3/컴팩션 데이터)을 읽을 때 사용합니다.
* Connector Scan Pool (pip_con_scan): *External Catalog*(Hive, Iceberg, Hudi, Delta Lake, S3 파일 등)를 통해 외부 데이터 레이크의 데이터를 읽을 때 사용합니다.
Shared-data 환경에서 CN(Compute Node)이 외부 카탈로그를 조회할 때, 이 스레드 풀을 사용하여 원격 스토리지(S3, HDFS 등)의 데이터를 병렬로 가져옵니다.
2. 왜 별도의 풀(Pool)을 사용하나요?
* 리소스 격리: StarRocks 내부 테이블 쿼리와 외부 데이터 레이크(Hive/Iceberg 등) 쿼리가 서로의 자원을 침범하지 않도록 분리합니다.
* I/O 특성 반영: 외부 스토리지(S3 등)는 네트워크 레이턴시가 발생할 수 있으므로, 내부 로컬 디스크 스캔과는 다른 동시성 제어가 필요합니다.
3. 관련 주요 설정 및 확인 방법
만약 쿼리 성능이 낮거나 외부 테이블 조회 시 병목이 의심된다면 아래 설정들을 살펴봅니다.
* 스레드 수 설정 (BE/CN 설정):
* `pipeline_connector_scan_thread_num_per_cpu`: CPU 코어당 할당할 커넥터 스캔 스레드 수입니다. (기본값 보통 8~16)
* 조회 방법 (SQL):
현재 시스템에서 커넥터 스캔 스레드가 어떻게 작동하는지 확인할 수 있습니다.
sql
-- 커넥터 스캔 스레드 정보 확인
SELECT * FROM information_schema.be_threads WHERE name LIKE '%pip_con_scan%';
* Profile 확인:
쿼리 프로파일(Query Profile)을 보면 CONNECTOR_SCAN_OPERATOR 항목 아래에 ScanTime, IOTaskWaitTime 등의 지표가 나타나는데, 여기서 Connector Scan Pool이 얼마나 효율적으로 동작했는지 알 수 있습니다.
요약
*Connector Scan Pool*은 Shared-data 아키텍처에서 *외부 카탈로그(데이터 레이크) 데이터를 읽어올 때 사용하는 일꾼(스레드)들의 집합*입니다. StarRocks 내부 테이블 데이터가 아닌, 외부 스토리지의 데이터를 가져오는 병렬 처리량을 결정하는 핵심 리소스라고 이해하시면 됩니다.
References
• administration/management/BE_configuration.md
• sql-reference/System_variable.md
• best_practices/query_tuning/query_profile_operator_metrics.md
• unloading/Spark_connector.md
• administration/management/resource_management/resource_group.mdRonJay
07/28/2026, 4:19 AMRocky
07/28/2026, 4:19 AMbe.conf or cn.conf and restart the node:
properties
datacache_enable = false
Note: This will stop both the memory-based Page Cache and the disk-based Block Cache.
* Partial Disable (Memory only):
If you want to keep the disk cache but disable the memory-based Page Cache:
properties
disable_storage_page_cache = true
──────────
2. What happens to the "Disk Cache" if you disable "Memory Cache"?
In StarRocks, Data Cache uses memory for two purposes: Data Storage (Page Cache) and Metadata/Indexing.
If you disable or limit the memory component (e.g., setting datacache_mem_size = 0 or disable_storage_page_cache = true):
1. Disk Cache still exists but becomes slower: The system will still attempt to use the disk (Block Cache), but because it cannot use memory as a high-speed buffer, every cache hit will require a physical disk I/O, increasing latency.
2. Metadata still requires Memory: Even if you disable the "data" part of the memory cache, the metadata (the index that tells StarRocks which blocks are stored where on the disk) must stay in memory.
* If you don't provide enough memory for this metadata, the disk cache will fail to initialize or will be unable to track cached files, effectively making the disk cache useless.
3. No Automatic Deletion: Disabling the memory component does not delete the data already written to the disk. The datacache directory on your disk will remain at its current size until you manually delete it:
bash
# Example: Clear disk cache manually if needed
rm -rf <your_storage_path>/datacache/*
Summary Recommendation
* If you want to save memory because of OOM issues, it is usually better to set datacache_enable = false entirely.
* Running a disk cache without a corresponding memory allocation for metadata often leads to the "NA" status in show proc '/compute_nodes' because the cache module fails to initialize properly.
References
• using_starrocks/caching/block_cache.md
• data_source/data_cache.md
• administration/management/BE_configuration.md
• data_source/data_cache_troubleshooting.md
References
• using_starrocks/caching/block_cache.md
• data_source/data_cache.md
• data_source/data_cache_troubleshooting.mdRonJay
07/28/2026, 5:08 AMRocky
07/28/2026, 5:08 AMSHOW PROC)
가장 간단하게 전체 노드의 캐시 상태를 확인하는 방법입니다.
sql
-- Compute Node(CN) 또는 Backend(BE)의 상태 확인
SHOW PROC '/compute_nodes';
-- 또는
SHOW PROC '/backends';
* 확인 항목: DataCacheMetrics 컬럼을 확인합니다.
* 결과 예시: {"l1_cache_hit_ratio": 0.85, "l2_cache_hit_ratio": 0.92, ...}
* L1 Cache: 메모리(Memory) 히트율
* L2 Cache: 디스크(Disk) 히트율
2. 개별 쿼리의 프로파일 확인 (Query Profile)
특정 쿼리가 실행될 때 캐시를 얼마나 썼는지 상세히 분석할 때 사용합니다.
sql
-- 쿼리 실행 후 프로파일 확인
SET pipeline_profile_level = 1;
-- 쿼리 실행...
-- 그 후 마지막 쿼리의 Profile ID 확인
SHOW LAST QUERY ORDER BY QueryId;
-- 상세 프로파일 확인
GET_QUERY_PROFILE('your_query_id');
* 주요 지표: SCAN_OPERATOR 섹션에서 아래 항목을 찾으세요.
* `DataCacheReadBytes`: 캐시 계층에서 읽으려고 시도한 전체 데이터양
* `DataCacheHitBytes`: 실제 캐시에서 읽어오는 데 성공한 데이터양
* 계산: `HitBytes / ReadBytes`가 해당 쿼리의 캐시 히트율입니다.
3. Prometheus 메트릭 (시계열 모니터링)
Grafana 등을 통해 대시보드를 구성할 때 사용하는 지표입니다. 각 BE/CN의 :8040/metrics 엔드포인트에서 제공됩니다.
* 메모리(L1) 관련:
* starrocks_be_data_cache_hit_bytes{level="l1"}
* starrocks_be_data_cache_read_bytes{level="l1"}
* 디스크(L2) 관련:
* starrocks_be_data_cache_hit_bytes{level="l2"}
* starrocks_be_data_cache_read_bytes{level="l2"}
* 전체 처리량:
* `starrocks_be_data_cache_read_request_total`: 전체 요청 수
* `starrocks_be_data_cache_skip_request_total`: 캐시를 타지 않고 건너뛴 요청 수
요약: 메모리 vs 디스크 구분법
* L1 (Level 1): 메모리 기반 캐시입니다. 속도가 가장 빠르지만 용량이 적습니다.
* L2 (Level 2): 디스크 기반 캐시입니다. 메모리보다는 느리지만 원격 스토리지(S3 등)보다는 훨씬 빠르며 대용량 저장이 가능합니다.
만약 `DataCacheMetrics`가 *`NA`*로 나온다면, 캐시 설정이 비활성화되어 있거나 메타데이터 초기화에 실패한 상태이므로 로그 확인이 필요합니다.
References
• data_source/data_cache_observe.md
• using_starrocks/caching/block_cache.md
• administration/management/monitoring/Metric_description.mdRonJay
07/29/2026, 4:03 AMRocky
07/29/2026, 4:04 AMQueryTimeout 값이 기대와 다른 이유는 크게 세 가지 가능성이 있습니다.
1. 리소스 그룹(Resource Group)의 타임아웃 제한
StarRocks의 리소스 그룹 기능이 활성화되어 있다면, 쿼리 타임아웃은 *"세션 변수(query_timeout) 값"*과 "리소스 그룹에 설정된 query_timeout 값" 중 *더 작은 값*으로 최종 결정됩니다.
* 만약 소속된 리소스 그룹의 타임아웃이 300초(5분)로 설정되어 있다면, 세션에서 1,200초로 늘려도 리소스 그룹의 설정값이 우선 적용됩니다.
* 확인 방법:
sql
-- 자신이 속한 리소스 그룹의 설정을 확인 (ADMIN 권한 필요)
SHOW RESOURCE GROUPS;
2. FE의 전역 설정 (max_query_timeout)
FE(Frontend) 설정 파일(fe.conf)에는 개별 쿼리가 가질 수 있는 최대 타임아웃 한계치인 max_query_timeout 항목이 있습니다.
* 만약 `fe.conf`에서 `max_query_timeout`이 1,200보다 작게 설정되어 있다면, 세션 변수를 아무리 크게 설정해도 이 시스템 상한선을 넘을 수 없습니다.
* 확인 방법: FE 로그나 설정을 확인하거나 `ADMIN SHOW CONFIG;`를 통해 확인 가능합니다.
3. `SHOW RUNNING QUERIES`의 출력 형식 이해
SHOW RUNNING QUERIES 명령에서 보여주는 QueryTimeout 컬럼은 "지속 시간(초)"이 아니라 *"쿼리가 종료(만료)될 시각(Timestamp)"*을 나타냅니다.
* 비교법: `StartTime`과 QueryTimeout 시각의 차이가 정확히 1,200초인지 확인해 보시기 바랍니다.
* 참고: 만약 `State`가 `PENDING`인 경우, PendingTimeout 시각이 별도로 표시되는데 이는 쿼리 큐(Queue)에서 대기할 수 있는 최대 시각입니다.
해결 방법 요약
1. 세션 설정 확인: 현재 세션에서 `SELECT @@query_timeout;`을 실행해 1200이 정상적으로 나오는지 먼저 확인하세요.
2. 리소스 그룹 확인: SHOW RESOURCE GROUPS; 명령어로 쿼리가 속한 그룹의 `CONCURRENCY_LIMIT`이나 QUERY_TIMEOUT 설정을 확인하세요.
3. 상한선 확인: 전역 타임아웃 설정을 변경하려면 `SET GLOBAL query_timeout = 1200;`을 시도해 보세요 (이 경우 새로 맺어지는 모든 세션에 적용됩니다).
만약 여전히 시각 차이가 크다면, 쿼리가 실행 중인 FE 노드의 시스템 시간(Clock) 동기화 상태도 점검해 보시는 것이 좋습니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md
• administration/management/resource_management/resource_group.md
• sql-reference/System_variable.md
• administration/management/resource_management/query_queues.md
References
• release_notes/release-4.0.md
• release_notes/release-2.1.mdRonJay
07/30/2026, 1:29 AMRocky
07/30/2026, 1:29 AMINSERT, UPDATE, DELETE 관련 명령인가요? (가장 가능성 높음)
StarRocks v3.4.0 버전부터 타임아웃 메커니즘이 변경되었습니다.
* query_timeout: 일반적인 SELECT 쿼리에만 적용됩니다.
* insert_timeout: INSERT INTO SELECT, UPDATE, DELETE, CTAS(Create Table As Select), 구체화된 뷰(MV) 새로고침 등 *데이터를 쓰는 작업*에 적용됩니다.
* `insert_timeout`의 기본값은 *14,400초(4시간)*입니다.
* 만약 수행 중인 쿼리가 INSERT INTO ... SELECT 형태라면, `query_timeout`을 1200초로 설정했더라도 기본값인 14,400초 동안 실행될 수 있습니다.
해결 방법: 해당 세션에서 `SET insert_timeout = 1200;`을 추가로 설정해 보세요.
──────────
2. "대기 시간(Pending)"과 "실행 시간(Running)"의 분리
StarRocks에서 쿼리의 전체 생명주기는 *[큐 대기 시간] + [실제 실행 시간]*으로 나뉩니다. 두 설정값은 각각 별개로 작동합니다.
* query_queue_pending_timeout_second (6000초): 쿼리가 리소스가 부족하여 큐에서 기다릴 수 있는 최대 시간입니다.
* query_timeout (1200초): 쿼리가 큐에서 빠져나와 *실제로 실행(Running)되기 시작한 시점*부터 적용되는 제한 시간입니다.
예시 시나리오:
1. 사용자가 쿼리를 던짐 (0초 시점)
2. 리소스가 부족해서 큐에서 1000초 동안 대기 (Pending 상태) -> 6000초 미만이므로 정상 대기.
3. 드디어 자원을 할당받아 실행 시작 (1000초 시점) -> 여기서부터 1200초 카운트다운 시작.
4. 실행 시작 후 500초 경과 (총 경과 시간 1500초).
5. 결과: 사용자가 보기에는 1200초가 지났지만(1500초 경과), 실행 시간은 500초뿐이므로 쿼리는 *정상 실행 중*입니다.
──────────
어떻게 확인하나요?
`SHOW RUNNING QUERIES`를 실행했을 때 나타나는 시간을 분석해 보세요.
* State 컬럼: 현재 `PENDING`인지 `RUNNING`인지 확인하십시오.
* StartTime vs 현재 시각: 쿼리가 '실행' 상태로 바뀐 시각부터 1200초가 지났는지 계산해 보셔야 합니다.
* Audit Log 확인: 쿼리가 끝난 후 `fe.audit.log`를 보면 `PendingTimeMs`(대기 시간)와 `QueryTimeMs`(실제 실행 시간)가 분리되어 기록됩니다.
요약
실행 중인 쿼리가 데이터 변경(INSERT 등) 작업이라면 `insert_timeout`을 확인하시고, 조회(SELECT) 작업이라면 쿼리가 큐에서 대기한 시간 때문에 전체 소요 시간이 길게 느껴지는 것일 수 있습니다.
References
• sql-reference/System_variable.md
• loading/InsertInto.md
• administration/management/resource_management/query_queues.md
• faq/loading/Insert_into_faq.md
References
• loading/InsertInto.md
• faq/loading/Insert_into_faq.md
• sql-reference/System_variable.md
• loading/loading_introduction/loading_considerations.md
• faq/operation_maintenance_faq.mdRonJay
07/30/2026, 1:42 AMRocky
07/30/2026, 1:42 AMbig_query_scan_rows_limit (가장 추천): 한 쿼리가 스캔할 수 있는 최대 행(Rows) 수입니다. Fragment가 많아지는 복잡한 쿼리는 보통 대량의 데이터를 스캔하므로, 이 값을 설정하면 효과적입니다.
* `big_query_cpu_second_limit`: 한 쿼리가 사용할 수 있는 최대 CPU 시간(초)입니다. Fragment 간의 데이터 이동(Shuffle)과 연산이 복잡할수록 CPU 사용량이 늘어나므로 이를 통해 제어 가능합니다.
* `big_query_mem_limit`: 한 쿼리가 각 BE 노드에서 사용할 수 있는 최대 메모리(Bytes)입니다.
* `concurrency_limit`: 해당 리소스 그룹 전체에서 동시에 실행될 수 있는 쿼리 수를 제한하여 자원 고갈을 방지합니다.
설정 예시 (SQL):
sql
ALTER RESOURCE GROUP your_group_name WITH (
'big_query_scan_rows_limit' = '10000000', -- 1,000만 건 이상 스캔 시 차단
'big_query_cpu_second_limit' = '100', -- CPU 시간 100초 초과 시 차단
'big_query_mem_limit' = '2147483648' -- 2GB 이상 메모리 사용 시 차단
);
──────────
2. EXPLAIN에서 확인해야 할 핵심 기준점
문제의 쿼리를 발견했을 때 EXPLAIN 명령어를 통해 해당 쿼리가 왜 "대규모"인지 판단하는 기준은 다음과 같습니다.
① PLAN FRAGMENT 개수 확인
EXPLAIN 결과 상단부터 아래로 내려가며 PLAN FRAGMENT 0, PLAN FRAGMENT 1 ... 이 몇 번 나오는지 확인합니다.
* 의미: Fragment가 많을수록 데이터 셔플(Exchange)이 빈번하고 네트워크 비용이 높다는 뜻입니다.
* 주의: 단순 Fragment 개수보다 FragmentInstances (Fragment 수 × 병렬도)가 실제 부하를 결정합니다.
② SCAN 노드의 cardinality (가장 중요)
OlapScanNode 또는 ExternalScanNode 섹션의 cardinality 값을 확인하세요.
* 기준: 이 값이 리소스 그룹의 `big_query_scan_rows_limit`에 근접하거나 수억 건 이상이라면 필터 조건(WHERE)이 누락되었거나 파티션 프루닝(Partition Pruning)이 제대로 작동하지 않는 쿼리일 가능성이 높습니다.
③ EXCHANGE 노드와 데이터 전송량
Fragment 사이를 연결하는 EXCHANGE 노드를 찾으세요.
* 확인 사항: `EXCHANGE(BROADCAST)`가 너무 큰 테이블에 적용되고 있지는 않은지 확인하세요. (작은 테이블이 아닌 큰 테이블을 모든 노드로 복사하면 네트워크 과부하가 발생합니다.)
④ Estimates (비용 예측값)
StarRocks v3.3.5+ 버전부터 `EXPLAIN`의 기본값이 `COSTS`로 변경되었습니다. 각 노드 옆의 Estimates 항목을 확인하세요.
* cpu, memory, network 수치가 비정상적으로 높은 연산자가 있다면 그 부분이 병목 지점입니다.
──────────
3. 실무적인 쿼리 제한 팁
* 병렬도 제한 (parallel_fragment_exec_instance_num): 특정 세션이나 리소스 그룹의 Fragment 인스턴스 수를 줄이고 싶다면 세션 변수로 이 값을 조절하여(기본값은 BE 코어 수의 절반) 쿼리당 점유하는 스레드 수를 제한할 수 있습니다.
* 쿼리 큐(Query Queue): 자원이 부족할 때 쿼리를 즉시 거절하지 않고 대기시키고 싶다면 query_queue_concurrency_limit 설정을 병행하는 것이 좋습니다.
요약하자면: `EXPLAIN`에서 *`cardinality`*가 너무 크거나 *`PLAN FRAGMENT`*가 지나치게 많은 쿼리를 찾고, 이를 바탕으로 리소스 그룹의 *`big_query_scan_rows_limit`*를 설정하여 시스템 전체의 안정성을 확보하세요.
References
• administration/management/resource_management/resource_group.md
• administration/management/monitor_manage_big_queries.md
• sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md
• faq/resource_isolation_faq.md
• best_practices/query_tuning/query_planning.md
• administration/management/resource_management/resource_group.md
• administration/management/monitor_manage_big_queries.md
• sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md
• faq/resource_isolation_faq.md
• best_practices/query_tuning/query_planning.md
ReferencesRonJay
07/30/2026, 2:09 AMRocky
07/30/2026, 2:09 AMANALYZE 태스크(통계 수집 작업) 대기 큐(Queue)가 가득 찼을 때의 동작과 쿼리 타임아웃과의 관계는 다음과 같습니다.
1. Analyze Task 한도(100개) 초과 시 동작
StarRocks에서 쿼리에 의해 트리거되는 자동 통계 수집 태스크의 대기 한도는 `connector_table_query_trigger_analyze_max_pending_task_num`(기본값 100) 등으로 관리됩니다.
* 태스크 드랍(Drop): 대기 큐가 꽉 찬 상태에서 새로운 통계 수집 요청이 들어오면, 해당 *Analyze 태스크는 생성되지 않고 무시(Dropped)*됩니다.
* 쿼리는 정상 진행: Analyze 태스크가 생성되지 않더라도, 해당 태스크를 트리거한 원래의 쿼리는 실패하지 않습니다. 다만, 최신 통계 정보가 없는 상태에서 쿼리 계획(Execution Plan)을 세우게 되므로 *최적이 아닌(Sub-optimal) 실행 계획*이 생성되어 쿼리 성능이 떨어질 수 있습니다.
2. `query_timeout`과의 관계
`query_timeout`은 "쿼리 실행 시간"에 대한 설정이며, Analyze 태스크의 성격에 따라 다르게 작동합니다.
* 자동/쿼리 트리거 Analyze (Asynchronous):
* 이 작업들은 백그라운드에서 비동기로 실행됩니다.
* 사용자가 던진 쿼리는 Analyze 태스크의 완료를 기다리지 않고 즉시 실행되므로, Analyze 태스크가 큐에서 밀려있거나 드랍된다고 해서 사용자 쿼리가 `query_timeout`으로 취소되지는 않습니다.
* 단, 나쁜 실행 계획 때문에 쿼리 자체가 물리적으로 오래 걸린다면 설정된 `query_timeout`에 걸려 취소될 수 있습니다.
* 수동 ANALYZE TABLE 명령 (Synchronous):
* 사용자가 직접 ANALYZE TABLE ... 명령을 실행한 경우, 이 명령 자체가 하나의 "쿼리"로 간주됩니다.
* 이때는 해당 세션의 *`query_timeout` 설정값이 적용*됩니다. 만약 통계 수집 작업이 큐에서 대기하거나 실행되는 시간이 `query_timeout`을 초과하면 해당 명령은 취소됩니다.
3. 요약 및 대처법
* 상태 확인: SHOW ANALYZE STATUS 명령을 통해 현재 통계 수집 작업들의 상태(PENDING, RUNNING, FAILED 등)와 실패 원인을 확인할 수 있습니다.
* 큐 사이즈 조정: 만약 태스크가 빈번하게 드랍된다면 FE 설정에서 관련 큐 사이즈를 늘릴 수 있습니다 (예: ADMIN SET CONFIG ("connector_table_query_trigger_analyze_max_pending_task_num" = "200");).
* 수동 수집: 특정 중요한 테이블의 통계가 계속 누락된다면, 서비스 부하가 적은 시간에 ANALYZE TABLE 명령으로 수동 수집을 완료하는 것이 좋습니다.
결론적으로, Analyze 태스크가 꽉 찼다고 해서 실행하려던 쿼리가 즉시 취소되지는 않으며, 기존 통계 정보를 바탕으로 쿼리가 계속 수행됩니다.
References
• administration/management/FE_configuration.md
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/ANALYZE_TABLE.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md
References
• administration/management/FE_configuration.md
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/ANALYZE_TABLE.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md
• sql-reference/System_variable.md
References
• administration/management/FE_configuration.md
• using_starrocks/Cost_based_optimizer.mdRonJay
07/30/2026, 6:14 AMRocky
07/30/2026, 6:14 AMquery_mem_limit 세션 변수는 쿼리가 실행되는 동안 *각 BE(Backend) 노드에서 개별적으로 적용되는 메모리 상한선*입니다. 이 변수가 쿼리 admission(큐 대기 및 실행 허용)과 실행 중 메모리 제어에 어떻게 작동하는지 상세히 설명해 드립니다.
1. 작동 방식의 핵심: "실시간 감시자(Watchdog)"
`query_mem_limit`은 쿼리가 시작되기 전에 메모리 사용량을 미리 예약(Reservation)하는 용도가 아니라, *실행 중에 메모리를 실시간으로 체크하는 하드 리밋(Hard Limit)*으로 작동합니다.
* 노드별 독립 적용: 만약 `query_mem_limit`을 10GB로 설정했다면, 쿼리는 각 BE 노드당 최대 10GB씩 사용할 수 있습니다. BE가 3대라면 이론적으로 전체 클러스터에서는 30GB까지 사용할 수 있는 셈입니다.
* 실행 중 즉시 차단: 쿼리가 동작하다가 어느 한 BE 노드라도 설정된 10GB를 단 1바이트라도 초과하는 순간, 해당 BE는 쿼리를 즉시 중단시키고 FE(Frontend)에 에러를 보고합니다. 이때 사용자는 Memory Exceed Limit 메시지를 받게 됩니다.
2. 쿼리 Admission(큐 대기) 시의 동작
사용자가 쿼리를 던졌을 때 큐(Queue)에서 기다릴지 말지를 결정하는 Admission Control 단계에서는 query_mem_limit 값 자체를 기준으로 삼지 않습니다. 대신 시스템의 *현재 상태*를 봅니다.
* 시스템 메모리 임계치 (query_queue_mem_used_pct_limit): StarRocks는 현재 BE 노드들의 *실제 메모리 사용률*을 체크합니다.
* 예를 들어, 전역 설정으로 BE 메모리의 80%가 사용 중일 때 큐잉을 하도록 설정되어 있다면, 새로 들어온 쿼리의 `query_mem_limit`이 얼마든 관계없이 현재 BE 메모리가 80%를 넘었으면 쿼리는 PENDING 상태로 대기하게 됩니다.
* 슬롯(Slots) 기반 관리: StarRocks 3.x 버전 이상에서는 쿼리당 슬롯을 할당하는데, 현재는 대부분 쿼리당 1개의 슬롯을 사용하므로 메모리 크기와 상관없이 동시 실행 쿼리 수(concurrency_limit)에 의해 admission이 결정되는 경우가 많습니다.
3. 헤비 쿼리 처리 시나리오
헤비 쿼리가 들어올 때 `query_mem_limit`은 다음과 같은 전략적 역할을 수행합니다.
1. 자원 독점 방지: 특정 사용자가 아주 복잡한 조인(Join)이나 대규모 집계를 수행할 때, 이 변수를 적절히 낮게 설정해두면 해당 쿼리가 BE 노드 전체의 메모리를 다 써버려서 시스템이 다운(OOM)되는 것을 막고 해당 쿼리만 골라 죽일 수 있습니다.
2. 리소스 그룹(Resource Group)과의 연계:
* 리소스 그룹 설정 내의 `big_query_mem_limit`도 비슷한 역할을 하지만, 이는 리소스 그룹 차원의 차단기(Circuit Breaker)입니다.
* `query_mem_limit`은 세션별로 더 세밀하게 조절하고 싶을 때(예: "이 특정 쿼리만 메모리를 더 써도 돼") 사용합니다.
4. 주의사항 및 팁
* Pipeline Engine 필수: 이 설정은 Pipeline 엔진이 활성화된 상태에서만 유효합니다 (최신 버전은 기본 활성).
* 기본값 0의 의미: 기본값이 0이면 해당 쿼리에 대한 별도의 메모리 제한이 없다는 뜻이며, 이 경우 BE 노드 전체의 메모리 한도(mem_limit)에 도달할 때까지 메모리를 사용하려 시도합니다.
* 에러 발생 시 대처: Memory Exceed Limit 에러가 발생하면, 해당 쿼리가 정말 많은 자원이 필요한 정당한 쿼리인지 확인한 후 `SET query_mem_limit = <더 큰 값>;`을 통해 한도를 높여줄 수 있습니다.
요약하자면: `query_mem_limit`은 쿼리를 들여보낼지 말지 결정하는 "입구 컷" 기준이라기보다, 일단 들어온 쿼리가 *실행 중에 선을 넘지 않도록 강제 종료시키는 "안전장치"*에 가깝습니다.
References
• sql-reference/System_variable.md
• administration/management/resource_management/Memory_management.md
• administration/management/resource_management/query_queues.md
• administration/management/resource_management/resource_group.md
• best_practices/audit_log_resource_group.md
• administration/management/resource_management/Memory_management.md
• administration/management/resource_management/Query_management.md
• sql-reference/System_variable.md
• administration/management/resource_management/query_queues.md
• best_practices/audit_log_resource_group.md
References
• sql-reference/System_variable.md
• administration/management/resource_management/Memory_management.md
• administration/management/resource_management/query_queues.mdRocky
07/30/2026, 6:14 AMRonJay
07/30/2026, 6:18 AMRocky
07/30/2026, 6:19 AMsql
-- 현재 세션에만 적용
SET query_mem_limit = 10737418240; -- 10GB (Byte 단위)
-- 전역 기본값으로 설정 (이후 접속하는 모든 세션에 적용)
SET GLOBAL query_mem_limit = 10737418240;
2. 노드당 쿼리 메모리 한도 설정 (Per-node Limit)
위에서 설명한 query_mem_limit 변수가 바로 노드당 한도를 정하는 방법입니다.
* 상한선: 이 값은 각 BE의 물리적 메모리 한도인 mem_limit (기본값: 전체 메모리의 90%) 내에서 작동해야 합니다.
* 권장 사항: 100대나 되는 대규모 노드 환경에서는 개별 쿼리가 한 노드의 자원을 독점하지 않도록 `query_mem_limit`을 전체 BE 메모리의 20~30% 정도로 낮게 유지하고, 필요할 때만 세션별로 높여서 사용하는 것이 안전합니다.
3. Connector Scanner와 `query_mem_limit`의 관계
결론부터 말씀드리면, `connector_scanner`가 사용하는 메모리는 `query_mem_limit`의 통제를 받습니다.
* 메모리 추적(Tracking): StarRocks의 메모리 관리자는 쿼리가 실행되는 동안 발생하는 모든 메모리 할당을 추적합니다. 여기에는 내부 테이블 스캔뿐만 아니라 Iceberg, Hudi, Parquet 등을 읽는 *Connector (External) Scanner*의 버퍼 메모리, 메타데이터 캐시 등도 포함됩니다.
* 동작 방식: 외부 데이터를 읽어올 때 사용하는 `ConnectorScanNode`는 데이터를 메모리 청크(Chunk) 단위로 읽어오는데, 이 과정에서 사용되는 메모리가 해당 쿼리의 메모리 트래커에 합산됩니다. 만약 스캐너가 데이터를 너무 많이 읽어와서 해당 노드의 `query_mem_limit`을 초과하면 쿼리는 Memory Exceed Limit 에러와 함께 종료됩니다.
* 스캐너 전용 제어: 스캐너가 사용하는 메모리를 더 세밀하게 조절하고 싶다면 아래 BE 설정을 참고할 수 있습니다 (단, 이 역시 결국 query_mem_limit 내에서 소비됩니다).
* `max_hdfs_scanner_num`: 노드당 동시에 실행될 수 있는 커넥터 스캐너 수 제한.
* `pipeline_connector_scan_thread_num_per_cpu`: CPU 코어당 할당되는 스캔 스레드 수 (스레드가 많을수록 할당되는 버퍼 메모리도 늘어남).
요약
1. 전체 제한: query_mem_limit * 노드 수(100대)가 쿼리 전체의 잠재적 사용량입니다.
2. 개별 제한: `SET query_mem_limit`을 통해 각 노드별 최대 메모리 사용량을 강제합니다.
3. 커넥터 스캐너: 외부 테이블 스캔 작업도 쿼리 메모리 한도에 포함되므로, `query_mem_limit`을 통해 제어 가능합니다.
References
• sql-reference/System_variable.md
• administration/management/BE_configuration.md
• administration/management/resource_management/Memory_management.md
• administration/management/resource_management/Query_management.md
• sql-reference/System_variable.md
• administration/management/BE_configuration.md
• administration/management/resource_management/Memory_management.md
• administration/management/resource_management/Query_management.md
References
• sql-reference/System_variable.md
• administration/management/BE_configuration.md
• administration/management/resource_management/Memory_management.md
• administration/management/resource_management/Query_management.md
• sql-reference/System_variable.md
• administration/management/BE_configuration.mdRocky
07/30/2026, 6:19 AM