<@U0A71G31CDV> starrocks spill to disk thresh hold...
# questions-and-troubleshooting
r
@Rocky starrocks spill to disk thresh hold option
r
StarRocks provides several threshold options to control when data "spills" to disk. Spilling is primarily managed through Resource Group settings, BE configurations, and session variables. To use any of these, you must first enable spilling:
Copy code
sql
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:
Copy code
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.md
r
@Rocky 동시쿼리 10개를 돌리는 데, cn pod의 cpu사용량이 20% 밖에안됨. 문제가뭘까? pipeline_dop 을 조정해야할까. auto이고 max만 조절해놓은 상태임
r
동시 쿼리 10개가 실행 중임에도 CN(Compute Node) Pod의 CPU 사용량이 20% 수준으로 낮다면, 이는 시스템이 할당된 자원을 충분히 활용하지 못하고 있거나(병목), *고병발(High Concurrency) 환경에서 안정성을 위해 스스로 병렬도를 낮추었을 가능성*이 큽니다. `pipeline_dop`을 `auto`로 설정하고 `max_pipeline_dop`만 조정하셨다면, 다음 단계별 체크포인트를 확인해 보시기 바랍니다. 1. `pipeline_dop = auto`의 적응형 로직 확인 (v3.0+) StarRocks의 `pipeline_dop`이 `auto(0)`일 경우, 시스템은 쿼리의 복잡도, 데이터 양, 그리고 현재 실행 중인 쿼리 수에 따라 병렬도를 동적으로 결정합니다. * 병렬도 저하 원인: 실행 중인 쿼리(10개)가 많다고 판단되면, 시스템 전체의 스케줄링 부하를 줄이기 위해 각 개별 쿼리의 `pipeline_dop`을 매우 낮게(심지어 1로) 설정할 수 있습니다. * 해결 시도:
SET 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.md
r
@Rocky starrocks 에서 cn 에 running query 는 0이면서 계속 큐에 쌓이기만하고, root user가 default db (_statistics) 에 DELETE FROM '_statistics_' "predicate_Columns' 쿼리만 계속 실행중이라면 원인이 무엇인가. 일반 사용자 쿼리는 하나도 실행 안되고 있
r
CN의 `NumRunningQueries`는 0인데 사용자의 쿼리는 계속 큐(Queue)에 쌓여
Pending
상태로 머물고,
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
쿼리를 강제 종료합니다.
Copy code
sql
-- 실행 중인 프로세스 목록 확인
SHOW FULL PROCESSLIST;

-- root가 실행 중인 DELETE 쿼리의 Id를 찾아 KILL
KILL <Connection_Id>;
2단계: 통계 정보 자동 수집 및 정리 일시 비활성화 정리 작업이 다시 실행되어 문제를 일으키지 않도록 FE 설정을 임시로 조정합니다.
Copy code
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.md
r
@Rocky statistics 가 문제를 일으키는지 어떻게 파악해?
r
통계 정보(Statistics) 관리 로직이 시스템 부하를 유발하거나 쿼리 지연의 원인이 되고 있는지 확인하는 구체적인 방법은 다음과 같습니다. 1. `SHOW FULL PROCESSLIST`로 직접 확인 (가장 확실함) 사용자가 이미 발견하신 것처럼,
root
사용자가 실행하는
DELETE FROM _statistics_...
또는
INSERT INTO _statistics_...
쿼리가 수천 초(Time) 이상 실행 중이라면 통계 정보 정리/수집 로직에 병목이 발생한 것입니다. * 특히 `State`가 `Waiting for lock`이거나, 다른 일반 쿼리들이
Planning
단계에서 멈춰 있다면 확신할 수 있습니다. 2.
_statistics_
내부 테이블 크기 확인
통계 정보가 담기는 내부 테이블에 데이터가 비정상적으로 많으면 정리 작업(
DELETE
)이 느려지고 락을 오래 잡게 됩니다.
Copy code
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
)이 있는지 확인합니다.
Copy code
sql
SHOW ANALYZE STATUS;
* `STATE`가 `RUNNING`인 작업이 너무 많거나, `FAILED`된 작업이 반복되고 있다면 FE에 과부하를 주고 있을 가능성이 큽니다. 5. FE 설정값 확인 (통계 정리 주기) 통계 정보 정리가 너무 자주 혹은 너무 드물게 일어나는지 설정을 확인합니다.
Copy code
sql
-- FE 설정 확인 (Admin 권한 필요)
ADMIN SHOW FRONTEND CONFIG LIKE '%statistic%';
* `statistic_cleanup_interval_sec`: 통계 정리 주기 (기본값 24시간). 이 값이 너무 작으면 정리가 너무 자주 발생합니다. * `enable_statistic_collect`: 통계 수집 활성화 여부. 요약: 문제가 확인되었다면? 만약 위 방법으로 통계 로직의 문제가 확인되었다면, 우선 실행 중인
DELETE
쿼리를
KILL
하여 서비스를 복구한 뒤, 다음 설정을 통해 자동 수집을 일시 중지하고 대용량으로 쌓인 통계 테이블을 정리해야 합니다.
Copy code
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.md
r
@Rocky enable_statistic_collect 를 끌경우 발생할 수 있는 사이드이펙트
r
`enable_statistic_collect`를 `false`로 설정하여 자동 통계 수집을 끌 경우 발생할 수 있는 주요 사이드이펙트는 다음과 같습니다. 1. CBO(비용 기반 옵티마이저)의 성능 저하 StarRocks의 CBO는 테이블의 데이터 양, 컬럼의 데이터 분포(NDV, Min/Max, Null count 등)를 바탕으로 최적의 실행 계획을 세웁니다. 통계 수집이 중단되면: * 부적절한 조인 순서(Join Reordering): 테이블 간의 크기 비교가 불가능해져, 작은 테이블을 메모리에 올리는(Broadcast) 대신 큰 테이블을 네트워크로 전송(Shuffle)하는 등 비효율적인 조인 방식을 선택할 수 있습니다. * 잘못된 실행 계획: 데이터가 대량으로 추가되거나 삭제되어도 옵티마이저는 과거 상태(혹은 아예 데이터가 없는 상태)를 기준으로 쿼리를 짜기 때문에, 쿼리 응답 속도가 급격히 느려질 수 있습니다. 2. 복잡한 쿼리(Multi-join)에서의 성능 폭락 단순한 쿼리보다 3개 이상의 테이블을 조인하거나 복잡한 서브쿼리가 포함된 경우, 통계 정보의 유무가 성능에 수십 배 이상의 차이를 만듭니다. 통계 정보가 없으면 옵티마이저가 '추측'에 의존하게 되어 가장 최악의 경로를 선택할 위험이 커집니다. 3. 신규 생성 테이블의 성능 최적화 불가
v3.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.md
r
@Rocky statistics 디비 테이블이 비대해졌는지 어떻게확인해?
r
_statistics_
데이터베이스 내 테이블이 비대해졌는지 확인하는 가장 빠르고 정확한 방법은 *시스템 명령어*와 *직접 쿼리*를 병행하는 것입니다. 1.
SHOW DATA
명령어로 용량 및 로우 수 확인
이 명령어는
_statistics_
DB 내의 모든 내부 테이블에 대해 물리적인 데이터 용량과 전체 로우(Row) 수를 한눈에 보여줍니다.
Copy code
sql
-- _statistics_ 데이터베이스 전체 테이블의 용량과 로우 수 확인
SHOW DATA FROM _statistics_;
* 체크 포인트:
Size
필드가 수 GB 이상이거나, `RowCount`가 수천만 건을 넘어가면 통계 정보가 과도하게 쌓여 있는 것으로 판단할 수 있습니다. 특히
column_statistics
테이블이 가장 비대해지기 쉽습니다. 2. 주요 통계 테이블별 로우 수 확인 직접 SQL을 실행하여 문제가 되는 특정 테이블의 크기를 확인합니다.
Copy code
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.md
r
@Rocky fe 와 cn 중 fe에 연결된 pvc 의 속도가 느리다면 이 병목을 해결해서 전체 클러스터의 속도를 개선하려면?
r
StarRocks 아키텍처에서 *FE(Frontend)*는 클러스터의 '두뇌' 역할을 하며, 모든 메타데이터(BDB JE)를 PVC에 저장합니다. FE의 디스크 속도가 느리면 쿼리 실행 계획 수립(Planning), 트랜잭션 처리, 통계 정보 관리 등 클러스터 전반의 성능이 급격히 저하됩니다. 이 병목을 해결하기 위한 구체적인 단계는 다음과 같습니다. 1. 스토리지를 고성능 SSD(Premium SSD/ESSD)로 교체 FE가 사용하는 메타데이터 저장소(BDB JE)는 *IOPS보다 지연 시간(Latency)*에 매우 민감합니다. * 조치: 현재 PVC의 StorageClass를 확인하고, 최소 3,000 IOPS 이상의 *SSD 기반 스토리지*로 업그레이드하세요. * 이유: 모든 데이터 삽입/수정(DML/DDL) 시 FE는 'Edit Log'를 디스크에 기록해야 합니다. 이 쓰기 속도가 느리면 클러스터 전체에
Waiting 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.md
r
@Rocky cn pod 에서 현재 실행중인 쿼리 몇개인지, Cpu는 어떻게 사용하고 있는지 확인하는법
r
CN Pod(또는 BE)에서 실행 중인 쿼리 수와 CPU 사용량을 확인하는 방법은 크게 *SQL 명령어*와 Kubernetes 명령어 두 가지가 있습니다. 1. SQL을 통한 확인 (가장 권장) StarRocks 내부 메트릭을 통해 각 노드별 상태를 한눈에 볼 수 있습니다. * CN 노드 전용 확인:
Copy code
sql
    SHOW COMPUTE NODES;
* NumRunningQueries: 해당 CN에서 현재 실행 중인 쿼리 수입니다. * CpuUsedPct: 해당 CN의 CPU 사용률(%)입니다. * 전체 백엔드(BE/CN 공통) 확인:
Copy code
sql
    SHOW PROC '/backends';
* `NumRunningQueries`와
CpuUsedPct
컬럼을 통해 동일한 정보를 확인할 수 있습니다. 2. 실행 중인 구체적인 쿼리 내용 확인 어떤 쿼리가 CPU를 많이 쓰고 있는지 상세 정보가 필요할 때 사용합니다. * 현재 FE에서 관리 중인 쿼리 목록:
Copy code
sql
    SHOW PROC '/current_queries';
    -- v3.4 이상에서 모든 FE의 쿼리를 보려면
    SHOW PROC '/global_current_queries';
*
QueryId
,
MemoryUsage
,
CPUTime
,
ExecTime
등을 확인할 수 있어 어떤 쿼리가 병목인지 파악하기 좋습니다. * 연결된 세션 상태 확인:
Copy code
sql
    SHOW PROCESSLIST;
3. Kubernetes 레벨에서 확인 (Pod별 물리 자원) StarRocks 엔진 내부 수치와 별개로, Pod가 실제로 소비하는 물리적 자원량을 확인하고 싶을 때 사용합니다.
Copy code
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.md
r
@Rocky starrocks fe current running query_count 329 query_queue_slot_running 10 failed_stats_collect_job external 8 externalFull 10 total_stats_collect_job external 189 externalFull 15 running_stats_collect_job external 1 externalFull 0
r
제공해주신 지표는 현재 *FE(Frontend)가 상당히 과부하 상태*이거나, 특정 작업에서 심각한 병목이 발생하고 있음을 나타냅니다. 특히 이전에 언급하신 *FE PVC 속도 저하*와 결합되어 시너지가 나고 있는 상황으로 보입니다. 지표별 상세 분석과 조치 방안입니다. 1. 쿼리 수와 큐 상태 (329 vs 10) * 상황: `current_running_query_count`가 *329*인데 반해, `query_queue_slot_running`은 *10*밖에 안 됩니다. * 의미: 대부분의 쿼리(319개)가 *쿼리 큐(Query Queue)나 리소스 그룹의 제한을 받지 않고 FE에 직접 부하*를 주고 있다는 뜻입니다. * 위험 요소: 300개가 넘는 쿼리가 동시에 Planning 단계를 거치면 FE의 CPU와 메모리 점유율이 치솟고, 특히 느린 PVC 때문에 메타데이터(BDB JE) 락(Lock) 경합이 발생하여 전체 클러스터가 느려집니다. 2. 통계 수집 실패 (
externalFull
10/15 실패)
* 상황: 전체 15건의
externalFull
통계 수집 작업 중 *10건이 실패*했습니다. 실패율이 66%에 달합니다. * 의미: `externalFull`은 외부 테이블(Hive, Iceberg 등)의 전체 데이터를 스캔하여 통계를 내는 *매우 무거운 작업*입니다. * 실패 원인 추정: 1. I/O 타임아웃: FE의 PVC가 느려 통계 정보를 쓰고 읽는 과정에서 타임아웃 발생. 2. 리소스 부족: FE가 329개의 쿼리를 처리하느라 백그라운드 작업인 통계 수집에 자원을 할당하지 못함. 3. 외부 카탈로그 지연: 외부 메타스토어와의 통신 문제. 3. 해결을 위한 권장 조치 ① 통계 수집 작업 상태 확인 (실패 원인 파악) 어떤 이유로 실패했는지 정확한 메시지를 확인해야 합니다.
Copy code
sql
SHOW ANALYZE STATUS WHERE Status = 'FAILED';
*
Reason
컬럼에 'Timeout', 'Memory exceed', 'Lock wait timeout' 등의 메시지가 있는지 확인하세요. ② 과도한 통계 수집 제한 (임시 조치) 만약 v3.4 이상을 사용 중이고 쿼리에 의해 자동으로 통계 수집이 유발되고 있다면, 잠시 꺼두어 FE의 숨통을 틔워줄 수 있습니다.
Copy code
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.md
r
@Rocky SHOW ANALYZE STATUs 결과로 나오는 데이터들이 뭘 의미하는거고, 여기서 failed 된 것은 그럼 뭘 의미하는건가?
r
`SHOW ANALYZE STATUS`는 StarRocks의 *CBO(Cost-Based Optimizer)가 쿼리 계획을 세울 때 사용하는 통계 정보(Statistics) 수집 작업의 상태*를 보여주는 명령어입니다. 1. 주요 컬럼의 의미 컬럼명 | 의미 Id | 통계 수집 작업의 고유 ID Database / Table | 통계 수집 대상 데이터베이스와 테이블 Columns | 통계가 수집된 구체적인 컬럼 목록 Type | 수집 방식 (`FULL`: 전체 스캔, `SAMPLE`: 샘플링 스캔, `HISTOGRAM`: 히스토그램) Status | 현재 상태 (`PENDING`: 대기, `RUNNING`: 실행 중, `FINISH`: 성공, `FAILED`: 실패) StartTime / EndTime | 작업 시작 및 종료 시간 Reason | (가장 중요) `Status`가 `FAILED`일 때, 왜 실패했는지에 대한 상세 이유 ────────── 2. 'FAILED'가 의미하는 것과 클러스터에 주는 영향 `FAILED`는 통계 정보를 수집하려고 시도했으나, 모종의 이유로 끝까지 완료하지 못하고 포기했다는 뜻입니다. 왜 실패했을까요? (사용자 상황 기반 추측) 사용자님의 현재 클러스터 상황(300개 이상의 쿼리 실행, 느린 FE PVC)을 고려할 때 실패 원인은 다음과 같을 가능성이 높습니다: 1. FE 메타데이터 쓰기 지연 (PVC 병목): 수집된 통계 정보를 FE가 자신의 메타데이터 저장소(BDB JE)에 기록해야 하는데, PVC가 너무 느려 쓰기 작업이 타임아웃(Timeout)된 경우. 2. 리소스 부족: `externalFull`은 외부 테이블 전체를 읽는 무거운 작업입니다. 현재 실행 중인 쿼리가 329개나 되어 CN/BE의 리소스가 부족해 통계 수집용 스캔 쿼리가 강제 종료되었을 수 있습니다. 3. 잠금 경합 (Lock Wait): FE가 다른 많은 쿼리를 처리하느라 메타데이터를 업데이트하기 위한 락을 오랫동안 점유하고 있어, 통계 수집 작업이 락을 얻지 못해 실패했을 수 있습니다. 실패하면 어떤 문제가 생기나요? * 잘못된 쿼리 실행 계획: Optimizer가 테이블에 데이터가 얼마나 있는지(Row count), 데이터 분포가 어떤지 최신 정보를 모르게 됩니다. * 성능 저하: 예를 들어, 실제로는 1억 줄인 테이블을 100줄로 착각하여 부적절한 Join 방식(Broadcast Join 등)을 선택하게 되고, 이는 곧 *쿼리 속도 저하와 시스템 다운*으로 이어질 수 있습니다. ────────── 3. 확인 방법 지금 바로 아래 명령어를 실행하여
Reason
컬럼을 확인해 보세요.
Copy code
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.md
r
@Rocky starrocks fe txn 메트릭은 뭘 의미하는가
r
StarRocks의 FE(Frontend) *TXN(Transaction) 메트릭*은 데이터 로딩(Stream Load, Routine Load, Insert 등) 과정에서 발생하는 *트랜잭션의 상태와 단계별 지연 시간(Latency)*을 나타냅니다. 사용자님의 상황(FE PVC 속도 저하 및 많은 쿼리 수)에서 이 메트릭들은 "왜 데이터 가시화(Visibility)가 늦어지는지" 또는 *"왜 FE가 쓰기 작업에서 병목을 겪는지"*를 진단하는 핵심 지표입니다. 1. 주요 TXN 메트릭 종류와 의미 ① 요청 및 상태 메트릭 *
txn_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.md
r
@Rocky 지금 무엇때문에 쿼리가 지연되고 있는지 파악이 힘든데 어떻게 접근해야됨?
r
지연의 원인을 정확히 파악하기 위해서는 *"병목이 FE(계획 단계)에 있는지, BE(실행 단계)에 있는지"*를 분리하는 것이 첫 번째 단계입니다. 329개의 쿼리가 동시에 실행 중인 현재 상황에서 가장 효과적인 접근 방법을 순서대로 정리해 드립니다. 1단계: FE vs BE 병목 지점 분리 (가장 빠름) FE의
fe.audit.log
파일을 확인하여 어떤 단계에서 시간이 소요되는지 확인하세요. * `PlanTime`이 높음: FE의 쿼리 최적화 및 메타데이터 조회 단계가 느린 것입니다. 현재 사용자님의 상황(느린 PVC + 329개 쿼리)에서는 이 가능성이 매우 높습니다. * `QueryTime`은 높지만 `PlanTime`은 낮음: 데이터 스캔이나 조인 연산 등 BE(Storage/Compute) 단계가 느린 것입니다. ────────── 2단계: 실시간 실행 쿼리 상태 확인 어떤 쿼리들이 자원을 점유하고 있는지 확인합니다.
Copy code
sql
-- 현재 실행 중인 쿼리와 각 쿼리의 진행 시간 확인
SHOW PROC '/current_queries';
* 여기서 `ScanBytes`나 `CpuCost`가 비정상적으로 높은 쿼리가 있다면 해당 쿼리가 전체 시스템의 IO나 CPU를 점유하고 있는 것입니다. ────────── 3단계: FE 내부 병목 진단 (사용자 상황 특화) 현재 *329개의 쿼리*가 돌아가고 있는데 *큐 슬롯은 10개*만 사용 중이라는 점은 매우 위험한 신호입니다. ① FE Lock 경합 확인 FE는 메타데이터를 읽고 쓸 때 Lock을 사용합니다. 쿼리가 너무 많으면 Lock 대기 시간이 길어집니다.
Copy code
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) 가장 느린 특정 쿼리 하나를 골라 상세 분석합니다.
Copy code
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.md
r
@Rocky Running 중인 쿼리 10개가 슬롯 전부를 차지했는데 이거 어떻게 종료 시켜?
r
슬롯(쿼리 큐)을 점유하고 있는 쿼리들을 종료하려면, 먼저 *어떤 쿼리가 실행 중인지 확인*한 뒤 그 *ID를 사용하여
KILL
명령어를 실행*해야 합니다. 1. 실행 중인 쿼리와 ID 확인하기 가장 먼저 어떤 쿼리가 자원을 먹고 있는지 확인합니다. 아래 명령어 중 하나를 사용하세요. * 방법 A (추천): 리소스 사용량까지 한눈에 확인
Copy code
sql
    SHOW PROC '/current_queries';
* 여기서
ConnectionId
또는
QueryId
컬럼을 확인하세요. * 방법 B: 표준 MySQL 방식
Copy code
sql
    SHOW FULL PROCESSLIST;
* 여기서
Id
컬럼이 해당 세션의 ID입니다. ────────── 2. 쿼리 종료하기 (KILL) 확인한 ID를 사용해 쿼리를 중단시킵니다. * 특정 쿼리만 종료 (연결은 유지):
Copy code
sql
    -- ConnectionId가 12345인 경우
    KILL QUERY 12345;
* 해당 연결(세션) 자체를 강제 종료:
Copy code
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.md
r
@Rocky Starrocks default wg 에 spill 메모리 수준 설정하는 법과 설정 가이드
r
StarRocks의 시스템 기본 리소스 그룹인 `default_wg`에 Spill(디스크 스왑) 임계치를 설정하는 방법과 권장 가이드는 다음과 같습니다. 1. 설정 방법
ALTER RESOURCE GROUP
명령어를 사용하여
spill_mem_limit_threshold
값을 수정합니다. 이 값은 해당 리소스 그룹에 할당된 메모리 중 어느 정도를 사용했을 때 디스크로 데이터를 흘릴(Spill) 것인지를 결정하는 비율(0~1)입니다.
Copy code
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. 세션 변수 활성화:
Copy code
sql
    SET GLOBAL enable_spill = true;
    SET GLOBAL spill_mode = 'auto'; -- 자동으로 임계치 도달 시 작동
3. 설정 가이드 및 권장 사항 ① 임계치 작동 원리 `default_wg`의 경우 기본적으로 `mem_limit`이 100%로 설정되어 있습니다. 따라서 다음과 같은 공식으로 Spill이 트리거됩니다:
트리거 시점 =
BE 전체 쿼리 메모리 제한
×
mem_limit(1.0)
×
spill_mem_limit_threshold
② 권장 값 (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. 설정 확인 명령어 설정이 잘 반영되었는지 확인하려면 아래 명령어를 사용하세요.
Copy code
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.md
r
@Rocky 아래 설정하려는데, SPILL MODE FORCE 인경우 어떻게 동작하는가
Copy code
sql
-- default_wg의 spill 임계치를 80%로 설정
ALTER RESOURCE GROUP default_wg WITH (
    'spill_mem_limit_threshold' = '0.8'
);
r
`spill_mode = 'force'`로 설정하면, 리소스 그룹에 설정한
spill_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.md
r
@Rocky Unknow property spill_mem_limit_threshhold in 4.0.4
r
4.0.4 버전에서 "Unknown property" 에러가 발생하는 이유는 프로퍼티 이름의 철자(Spelling) 오류 때문일 가능성이 매우 높습니다. 사용자께서 적어주신 에러 메시지를 보면 `threshhold`라고 'h'가 두 번 들어가 있습니다. StarRocks에서 사용하는 정확한 명칭은 *`threshold`*('h'가 하나)입니다. 1. 올바른 쿼리 (철자 수정) 아래와 같이 `threshold`로 철자를 수정해서 실행해 보세요.
Copy code
sql
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`가 존재하면 활성화된 상태입니다.) * 지원 속성 확인: 현재 사용 중인 버전에서 리소스 그룹이 지원하는 정확한 컬럼명들을 확인하려면 아래 명령어를 사용해 보세요.
Copy code
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.md
• administration/management/monitoring/Audit_log.md • administration/management/monitoring/metrics.md • using_starrocks/Query_planning.md • sql-reference/information_schema/be_txns.md • loading/StreamLoad.md • administration/management/FE_configuration.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md • administration/management/monitoring/Query_profile_overview.md • sql-reference/information_schema/analyze_status.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md • knowledge/trouble_shooting/fe_deadlock_problems.md • administration/Meta_recovery.md • administration/management/monitor_manage_big_queries.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.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 • faq/Sql_faq.md • using_starrocks/running_queries.md • quick_start/shared_nothing.md • sql-reference/sql-statements/account-management/ALTER_USER.md • sql-reference/sql-statements/account-management/SHOW_PROPERTY.md 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 • 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.md • administration/management/monitoring/Audit_log.md • administration/management/monitoring/metrics.md • using_starrocks/Query_planning.md • sql-reference/information_schema/be_txns.md • loading/StreamLoad.md • administration/management/FE_configuration.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md • administration/management/monitoring/Query_profile_overview.md • sql-reference/information_schema/analyze_status.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md • knowledge/trouble_shooting/fe_deadlock_problems.md • administration/Meta_recovery.md • administration/management/monitor_manage_big_queries.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.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 • faq/Sql_faq.md • using_starrocks/running_queries.md • quick_start/shared_nothing.md • sql-reference/sql-statements/account-management/ALTER_USER.md • sql-reference/sql-statements/account-management/SHOW_PROPERTY.md • releasenotes/4.0.md • administration/management/monitoring/Query_detail_overview.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/resource_management/resource_group.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/Memory_management.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • using_starrocks/Query_planning.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md
• sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md
• administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md
• administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md
• sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md
• administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md
r
@Rocky spill mem_limit_threshold 0.8 로 설정하고 query_queue_mem_used_pct_limit 을 0.6으로 설정했을때 만약 Cn이 쿼리를 처리하다가 메모리사용량이 높아지면 어떤 로직으로 메모리 spill을 하게되는가
r
CN(Compute Node) 또는 BE에서 두 설정(
query_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.md
r
@Rocky diskspill 이 시작되면 cn 메모리 중 어떤걸 디스크에 쓰는가 예를들면 process mem 안에 속해있는 것 중 쿼리 메모리?
r
Disk Spill(Spill to disk)이 시작될 때 디스크로 기록되는 메모리는 전체 Process Memory가 아니라, *쿼리 실행 중에 발생하는 '연산자별 중간 결과물(Intermediate Results)'*입니다. 사용자께서 질문하신 "Process Memory 안에 속해있는 쿼리 메모리"라는 표현이 정확합니다. 더 구체적인 범위와 로직은 다음과 같습니다. 1. 무엇을 디스크에 쓰는가? 전체 쿼리 메모리를 통째로 옮기는 것이 아니라, 메모리를 많이 점유하는 *특정 연산자의 내부 데이터 구조*를 디스크로 보냅니다. * Hash Join: 조인을 위해 메모리에 빌드해 둔 *Hash Table*의 일부 파티션을 디스크로 보냅니다. * Aggregate: 그룹화(Group By) 연산을 위해 생성된 Hash Table 데이터를 디스크에 기록합니다. * Sort: 정렬을 위해 메모리에 들고 있는 *정렬 블록(Sorted runs)*들을 디스크로 보냅니다. * CTE: 공통 테이블 식(Common Table Expression)의 중간 결과 데이터를 디스크에 저장합니다. 2. 메모리 계층 구조에서의 위치 CN/BE의 메모리는 크게 다음과 같이 나뉘는데, Spill은 오직 *Query Memory 내의 특정 영역*에만 관여합니다. * Process Memory (전체) * Metadata / Caches (Page Cache 등): (Spill 대상 아님) * Query Memory (쿼리 실행용) * Expression Evaluation (계산식 평가용): (Spill 불가) * Operator Intermediate Data (Join/Agg/Sort 등): (Spill 대상 ✅) * Result Buffer (결과 전송용): (Spill 대상 아님) 3. Spill 로직의 핵심 (동작 방식) 메모리가 임계치(예: 80%)에 도달하면 무작위로 데이터를 쓰는 것이 아니라, 아래와 같은 순서로 동작합니다. 1. 대상 탐색: 현재 실행 중인 쿼리들 중 'Spill 가능한 연산자'를 가진 쿼리를 찾습니다. 2. 직렬화 및 기록: 해당 연산자가 들고 있는 Hash Table 등의 데이터를 *직렬화(Serialization)*하여 `spill_local_storage_dir`에 지정된 파일로 씁니다. 3. 메모리 해제: 디스크에 기록이 완료된 부분만큼 메모리 주소 공간을 비웁니다. 4. 필요 시 재로드: 쿼리 연산이 다음 단계로 넘어가서 디스크에 있는 데이터가 다시 필요해지면, 다시 메모리로 읽어 들여 연산을 마무리합니다. 4. 중요한 예외 (디스크에 못 쓰는 것) 다음 항목들은 아무리 메모리가 부족해도 디스크로 Spill 할 수 없습니다. * Expression Evaluation:
A + 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.md
• sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • loading/StreamLoad.md • administration/management/monitoring/Audit_log.md • administration/management/monitoring/metrics.md • using_starrocks/Query_planning.md • sql-reference/information_schema/be_txns.md • administration/management/FE_configuration.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md • administration/management/monitoring/Query_profile_overview.md • sql-reference/information_schema/analyze_status.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md • knowledge/trouble_shooting/fe_deadlock_problems.md • administration/Meta_recovery.md • administration/management/monitor_manage_big_queries.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • faq/Sql_faq.md • using_starrocks/running_queries.md • sql-reference/sql-statements/account-management/ALTER_USER.md • sql-reference/sql-statements/account-management/SHOW_PROPERTY.md • releasenotes/4.0.md • administration/management/monitoring/Query_detail_overview.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md
• sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/resource_management/resource_group.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/Memory_management.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • sql-reference/System_variable.md • using_starrocks/Query_planning.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md
• administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md
• administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md
• administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md
• sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md
• administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md
• sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md
• administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/spill_to_disk.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/resource_group/SHOW_RESOURCE_GROUPS.md • administration/management/resource_management/Memory_management.md
r
@Rocky 쿼리들의 지연 속도와 처리 속도를 알기 위한 메트릭은?
r
StarRocks에서 쿼리의 *지연 시간(Latency)*과 *처리량(Throughput)*을 모니터링하기 위한 핵심 메트릭은 주로 *FE(Frontend)*에서 수집됩니다. Prometheus와 Grafana를 통해 확인할 수 있는 주요 메트릭은 다음과 같습니다. 1. 쿼리 지연 속도 (Latency) 관련 메트릭 쿼리가 실행되어 결과가 반환될 때까지 걸리는 시간을 측정합니다. 평균값보다는 *P99, P90*과 같은 분위수 메트릭을 보는 것이 "개별 쿼리가 얼마나 느린가"를 판단하는 데 훨씬 유리합니다. *
starrocks_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.md
• administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/management/resource_management/Memory_management.md • sql-reference/System_variable.md • using_starrocks/Query_planning.md • administration/management/resource_management/spill_to_disk.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 • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • faq/Resource_group_faq.md • administration/management/resource_management/Query_management.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/information_schema/analyze_status.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md • knowledge/trouble_shooting/fe_deadlock_problems.md • administration/Meta_recovery.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • loading/StreamLoad.md • sql-reference/information_schema/be_txns.md • quick_start/shared_nothing.md • sql-reference/sql-statements/account-management/ALTER_USER.md • sql-reference/sql-statements/account-management/SHOW_PROPERTY.md • using_starrocks/caching/query_cache.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md
• 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.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/management/resource_management/Memory_management.md • sql-reference/System_variable.md • using_starrocks/Query_planning.md • administration/management/resource_management/spill_to_disk.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 • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • faq/Resource_group_faq.md • administration/management/resource_management/Query_management.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/information_schema/analyze_status.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md • knowledge/trouble_shooting/fe_deadlock_problems.md • administration/Meta_recovery.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • loading/StreamLoad.md • sql-reference/information_schema/be_txns.md • quick_start/shared_nothing.md • sql-reference/sql-statements/account-management/ALTER_USER.md • sql-reference/sql-statements/account-management/SHOW_PROPERTY.md • using_starrocks/caching/query_cache.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • 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.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/management/resource_management/Memory_management.md • sql-reference/System_variable.md • using_starrocks/Query_planning.md
• administration/management/resource_management/spill_to_disk.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 • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • faq/Resource_group_faq.md • administration/management/resource_management/Query_management.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/information_schema/analyze_status.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md • knowledge/trouble_shooting/fe_deadlock_problems.md • administration/Meta_recovery.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • loading/StreamLoad.md • sql-reference/information_schema/be_txns.md • quick_start/shared_nothing.md • sql-reference/sql-statements/account-management/ALTER_USER.md • sql-reference/sql-statements/account-management/SHOW_PROPERTY.md • using_starrocks/caching/query_cache.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • 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.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/management/resource_management/Memory_management.md • sql-reference/System_variable.md • using_starrocks/Query_planning.md • administration/management/resource_management/spill_to_disk.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 • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • faq/Resource_group_faq.md • administration/management/resource_management/Query_management.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/information_schema/analyze_status.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md • knowledge/trouble_shooting/fe_deadlock_problems.md • administration/Meta_recovery.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• loading/StreamLoad.md • sql-reference/information_schema/be_txns.md • quick_start/shared_nothing.md • sql-reference/sql-statements/account-management/ALTER_USER.md • sql-reference/sql-statements/account-management/SHOW_PROPERTY.md • using_starrocks/caching/query_cache.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • 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.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/management/resource_management/Memory_management.md • sql-reference/System_variable.md • using_starrocks/Query_planning.md • administration/management/resource_management/spill_to_disk.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
• sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • faq/Resource_group_faq.md • administration/management/resource_management/Query_management.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/information_schema/analyze_status.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md • knowledge/trouble_shooting/fe_deadlock_problems.md • administration/Meta_recovery.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • loading/StreamLoad.md • sql-reference/information_schema/be_txns.md • quick_start/shared_nothing.md • sql-reference/sql-statements/account-management/ALTER_USER.md • sql-reference/sql-statements/account-management/SHOW_PROPERTY.md • using_starrocks/caching/query_cache.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • 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.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/management/resource_management/Memory_management.md • sql-reference/System_variable.md • using_starrocks/Query_planning.md • administration/management/resource_management/spill_to_disk.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 • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • faq/Resource_group_faq.md • administration/management/resource_management/Query_management.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/information_schema/analyze_status.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md • sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md • knowledge/trouble_shooting/fe_deadlock_problems.md • administration/Meta_recovery.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • loading/StreamLoad.md • sql-reference/information_schema/be_txns.md • quick_start/shared_nothing.md • sql-reference/sql-statements/account-management/ALTER_USER.md
• sql-reference/sql-statements/account-management/SHOW_PROPERTY.md • using_starrocks/caching/query_cache.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • 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.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/management/resource_management/Memory_management.md • sql-reference/System_variable.md • using_starrocks/Query_planning.md • administration/management/resource_management/spill_to_disk.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 • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • faq/Resource_group_faq.md • administration/management/resource_management/Query_management.md • using_starrocks/Cost_based_optimizer.md
r
@Rocky exec state report failed status=errorCode CANCELLED Memory of process exceed limit try consume 13215557641 Used 45327924095 LIMIT 55662776155 Mem usage has exceed the limit of BE 전에는 Usaed 랑 Limit 이 동일해서 에러가 발생했는데, 지금은 used lmit 이 줄었어. mem limit 이 들어간거 같은데 혹시 어떤 설정 때문일까 query_queue_mem_usaed_pct_limit 0.8 인데 이거 영향 있는거야?
r
보여주신 에러 메시지를 분석해보면, *`query_queue_mem_used_pct_limit` 설정이 직접적으로 이 쿼리를 킬(Kill)한 것은 아니지만, 시스템이 한계치에 도달했음을 보여주는 지표*가 됩니다. 결론부터 말씀드리면, 이번 에러는 *"개별 쿼리가 한 번에 너무 큰 메모리(약 12.3GB)를 추가로 할당받으려다 프로세스 전체 제한을 넘겼기 때문"*입니다. 상세한 이유는 다음과 같습니다. 1. 에러 메시지 수학적 분석 * LIMIT (전체 제한): 55,662,776,155 (약 51.84 GB) * Used (현재 사용 중): 45,327,924,095 (약 42.21 GB) * Try consume (추가 할당 시도): 13,215,557,641 (약 12.3 GB) 현재 사용량(42.21GB)에 추가 시도량(12.3GB)을 더하면 *54.51GB*가 됩니다. 이는 전체 제한인 *51.84GB를 초과*하기 때문에 할당이 거부되고 쿼리가 취소된 것입니다. 2.
query_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.md
r
@Rocky alter resource group default_wg WITH ( 'spill_mem_limit_threshold' = '0.9' ) 로 설정한 것 어떻게 초기화해?
r
리소스 그룹(
default_wg
)의 특정 속성을 초기화(Reset)하는 별도의 "UNSET" 명령어나 "DROP" 명령은 StarRocks에 존재하지 않습니다. 따라서 *해당 속성의 기본값(Default value)으로 다시 `ALTER`를 수행*하여 초기화해야 합니다.
spill_mem_limit_threshold
속성의 기본값은 *`1` (또는
1.0
)*이며, 이는 리소스 그룹 차원의 Spill 임계치를 사실상 비활성화(사용하지 않음) 상태로 두는 것을 의미합니다. 1. 초기화 명령어 다음 명령어를 실행하여 원래의 기본값인 `1`로 되돌릴 수 있습니다.
Copy code
sql
ALTER RESOURCE GROUP default_wg WITH ( 'spill_mem_limit_threshold' = '1' );
2. 설정 확인 방법 값이 정상적으로 변경되었는지 확인하려면 다음 명령어를 사용하세요.
Copy code
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.md
r
@Rocky pod memory를 늘렸는데 data cache 랑 page cache 도 늘어났음. 이거어떤 설정때문에 그런거야?
r
Pod의 메모리를 늘렸을 때 Data Cache와 Page Cache가 자동으로 늘어난 이유는 StarRocks BE(Backend)의 메모리 자동 계산 설정 때문입니다. StarRocks는 관리 편의를 위해 주요 메모리 지표들을 절대값이 아닌 *전체 메모리에 대한 백분율(%)*로 관리하는 경우가 많습니다. 1.
mem_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의 구성 정보를 조회해 보세요.
Copy code
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.md
r
@Rocky starrocks ui에서 쿼리 조회 후 Profile 눌러봤는데 Query is not found가 발생하는 이유는?
r
StarRocks Web UI에서 "Query is not found" 에러가 발생하는 가장 대표적인 이유는 다음과 같습니다. 1. Leader FE가 아닌 다른 FE 접속 (가장 흔한 이유) StarRocks의 쿼리 프로파일(Profile)은 *Leader FE*의 메모리에만 저장되고 관리됩니다. * 원인: 현재 브라우저로 접속한 FE가 Follower 또는 Observer인 경우, 쿼리 리스트는 보일 수 있으나 상세 프로파일 데이터를 불러오지 못할 수 있습니다. * 해결:
SHOW FRONTLENDS;
명령어로 `IsLeader`가 `true`인 FE의 IP로 직접 접속하여 확인하세요. 2.
enable_profile
설정 미비
기본적으로 StarRocks는 성능 오버헤드를 줄이기 위해 모든 쿼리의 프로파일을 생성하지 않습니다. * 원인:
enable_profile
변수가 `false`(기본값)로 되어 있으면 상세 프로파일이 생성되지 않습니다. * 해결: 쿼리 실행 전에 아래 명령어를 실행해야 합니다.
Copy code
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 클라이언트에서 직접 조회를 시도해 보세요.
Copy code
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.md
r
@Rocky STarrocks datacache mem 사용 안하게 하는거랑 data disk cache 도 사용 안하게 하는 옵션
r
StarRocks에서 Data Cache(Remote Storage 캐시)를 메모리와 디스크 모두 사용하지 않도록 설정하려면
be.conf
파일을 수정하거나
ADMIN SET CONFIG
명령을 사용할 수 있습니다. 1. 전체 비활성화 (가장 확실한 방법) Data Cache 기능 자체를 완전히 끄려면
datacache_enable
설정을 `false`로 변경합니다. 이 설정은 메모리(Page Cache 영역)와 디스크(Block Cache 영역) 캐시를 모두 비활성화합니다. * 설정 위치:
be.conf
* 설정 값:
Copy code
properties
    datacache_enable = false
(참고: 이 설정은 BE 재시작이 필요할 수 있습니다.) ────────── 2. 메모리 및 디스크 캐시 개별 비활성화 전체 기능을 끄지 않고 각각의 크기(Quota)를 0으로 만들어 사용하지 않게 설정할 수도 있습니다. 이 방법은 실행 중인 클러스터에서 즉시 적용할 때 유용합니다. (1) Data Cache 메모리 사용 안 함 Data Cache에서 메모리 점유를 막으려면 `datacache_mem_size`를 `0`으로 설정합니다.
Copy code
sql
ADMIN SET CONFIG ("datacache_mem_size" = "0");
(2) Data Cache 디스크 사용 안 함 디스크 캐시 용량을 `0`으로 설정하여 디스크 쓰기를 막습니다.
Copy code
sql
ADMIN SET CONFIG ("datacache_disk_size" = "0");
────────── 3. 추가적인 세부 옵션 (버전에 따라 상이) 일부 환경이나 버전에 따라 아래 옵션을 추가로 확인할 수 있습니다. * Block Cache(디스크 캐시) 비활성화:
Copy code
properties
    block_cache_enable = false
* Storage Page Cache(내부 테이블용 메모리 캐시) 비활성화: 데이터 레이크 캐시 외에 일반적인 테이블의 Page Cache도 끄고 싶다면 아래 옵션을 사용합니다.
Copy code
properties
    disable_storage_page_cache = true
설정 확인 방법 설정이 정상적으로 적용되었는지 확인하려면 SQL 클라이언트에서 다음 명령을 실행하세요.
Copy code
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.md
r
@Rocky show proc compute nodes 했을때 MEMUSEDPCT랑 일부 정보가 안보일경우 어떻게함
r
SHOW 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.md
r
@Rocky starrocks 4.1.1 버전에서쿼리 큐 v2 사용 가이드라인 만들어줘. 예를 들면 메모리 헤비쿼리, cpu 헤비쿼리 섞여서 들어올때 효율적으로 동시처리되도록
r
StarRocks 4.1.1 버전에서 *Query Queue v2*는 기본적으로 활성화(
enable_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`을 조절합니다.
Copy code
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
설정을 강화합니다.
Copy code
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
)를 동적으로 조절합니다. 부하가 높을 때 새 쿼리의 병렬도를 낮춰 자원 경합을 줄입니다.
Copy code
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 노드 전체의 자원이 위험 수준에 도달하면 무조건 큐에 대기시킵니다.
Copy code
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
컬럼을 확인하세요.
Copy code
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.md
r
@Rocky starrocks fe 에서 특정 Cn 이 해제가 안되는데 이거 삭제하는법
r
StarRocks 4.1.1 버전 및 최신 버전에서 특정 CN(Compute Node)이
ALTER SYSTEM DROP COMPUTE NODE
명령어로도 삭제되지 않고 목록에 남아있다면, 다음 단계별 조치 방법을 확인해 보시기 바랍니다. 1. 정확한 주소 확인 및 기본 명령어 실행 가장 먼저
SHOW PROC '/compute_nodes';
명령어를 통해 해당 CN의 *정확한 IP와 HeartbeatPort*를 확인하세요. 간혹 호스트네임과 IP 혼용으로 인해 명령어가 먹히지 않는 경우가 있습니다.
Copy code
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.md
r
@Rocky 수동으로 editlog image compaction 하는방법
r
StarRocks에서 FE(Frontend)의 메타데이터 로그(EditLog)를 수동으로 이미지 파일로 병합(Compaction/Checkpoint)하는 방법은 다음과 같습니다. 1. SQL 명령어를 통한 수동 생성 가장 간단하고 권장되는 방법은
ALTER SYSTEM
명령어를 사용하는 것입니다. 이 명령은 Leader FE에서 비동기적으로 체크포인트를 수행하여 새로운 이미지 파일을 생성하도록 트리거합니다.
Copy code
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) 설정값 확인 및 임시 변경:
Copy code
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.md
r
@Rocky starrocks 쿼리킬 명령어
r
StarRocks에서 실행 중인 쿼리를 중단(Kill)하는 방법은 크게 두 가지 단계로 나뉩니다. 1. 실행 중인 쿼리의 ID 확인 먼저 중단할 쿼리의 *Connection ID*(또는 Query ID)를 찾아야 합니다.
Copy code
sql
SHOW PROCESSLIST;
* Id: Connection ID (이 번호를 Kill 명령어에 사용합니다). * User: 쿼리를 실행한 사용자. * Time: 쿼리가 실행된 시간(초). * Info: 실행 중인 SQL 문장. 만약 특정 데이터베이스나 사용자 쿼리만 보고 싶다면 다음과 같이 필터링할 수 있습니다.
Copy code
sql
-- 실행 시간이 60초 이상인 쿼리만 확인
SELECT * FROM information_schema.exec_queries WHERE duration > 60;
────────── 2. 쿼리 중단 (Kill) 명령어 확인한 ID를 사용하여 쿼리를 종료합니다. (1) 특정 쿼리만 종료 (추천) 세션(연결)은 유지하고 현재 실행 중인 쿼리만 즉시 중단합니다.
Copy code
sql
KILL QUERY <connection_id>;
예:
KILL QUERY 12345;
(2) 세션 자체를 종료 쿼리를 포함하여 해당 사용자의 *데이터베이스 연결(세션) 자체*를 강제로 끊습니다.
Copy code
sql
KILL <connection_id>;
예:
KILL 12345;
────────── 3. 대량 적재(Load) 작업 중단 일반 SQL 쿼리가 아니라 `ROUTINE LOAD`나
INSERT INTO
같은 적재 작업을 중단하려면 별도의 명령어를 사용해야 합니다. * INSERT INTO 쿼리: 위와 동일하게
KILL
명령어를 사용합니다. * Routine Load (Kafka 등):
Copy code
sql
    STOP ROUTINE LOAD FOR <job_name>;
* Stream Load / Broker Load:
Copy code
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.md
r
@Rocky 다른 클러스터(더 작은 사이즈) 에서는 잘 동작하는 쿼리가 더 큰 규모의 클러스터에서 동작하지 않는 원인 파악하기 위한절차 쿼리 실행해보니 계속 대기중
r
규모가 큰 클러스터에서 쿼리가 "대기 중(Pending/Hanging)" 상태로 머무는 것은 단순히 연산이 느린 것과는 다른 원인(주로 자원 할당이나 잠금 문제)일 가능성이 높습니다. 원인 파악을 위한 단계별 절차는 다음과 같습니다. 1. 쿼리 상태 확인 (어디서 대기 중인가?) 가장 먼저 쿼리가 실행 시작도 못 했는지(Queueing), 아니면 *실행 중에 멈췄는지*를 구분해야 합니다. *
SHOW 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)에서 시간이 끌리는지 확인해야 합니다.
Copy code
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.md
• administration/management/resource_management/resource_group.md • administration/management/resource_management/workload_group.md • administration/management/resource_management/resource_management.md • administration/Execution_architecture.md • administration/Control_architecture.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_BACKENDS.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_FRONTENDS.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md • administration/Query_planning.md • sql-reference/sql-statements/data-manipulation/EXPLAIN.md • sql-reference/sql-statements/cluster-management/nodes_processes/SET_PROPERTY.md • sql-reference/sql-statements/cluster-management/nodes_processes/ADMIN_SHOW_CONFIG.md • sql-reference/sql-statements/cluster-management/nodes_processes/ADMIN_SET_CONFIG.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_VARIABLE.md • sql-reference/sql-statements/cluster-management/nodes_processes/SET_VARIABLE.md • administration/management/monitoring/Monitor_and_Alert.md • administration/management/monitoring/Metrics.md • administration/management/monitoring/alert.md • sql-reference/sql-statements/cluster-management/nodes_processes/CANCEL_QUERY.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • faq/loading/Loading_faq.md • faq/Select_faq.md • faq/Troubleshooting_faq.md • administration/Statistics.md • using_starrocks/Cost_based_optimizer.md • using_starrocks/Query_acceleration_with_auto_refresh_mv/Analyze_query_plan_with_mv.md
• administration/analyze_query_plan.md • administration/Cluster_administration.md • administration/management/Management_overview.md • administration/management/Scale_up_down.md • administration/management/Upgrade.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • administration/management/CN_configuration.md • table_design/distribute_system/Data_distribution.md • table_design/distribute_system/Bucketing.md • table_design/distribute_system/Colocate_join.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_DATA.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_TABLE_STATUS.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_TABLET.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • sql-reference/sql-statements/cluster-management/nodes_processes/ALTER_SYSTEM.md • sql-reference/sql-statements/cluster-management/nodes_processes/ALTER_LOAD_ERROR_URL.md • introduction/Architecture.md • introduction/StarRocks_intro.md • quick_start/StarRocks_intro.md • quick_start/Deployment_overview.md • deployment/Deployment_overview.md • deployment/Enterprise_edition_deployment.md • deployment/Community_edition_deployment.md • deployment/Deployment_recommendation.md • deployment/Environment_configurations.md • deployment/helm.md • deployment/operator.md • deployment/docker.md • administration/management/High_availability.md • administration/management/Multi_FE_Deployment.md
• administration/management/Replication_and_Consistency.md • administration/management/Load_balancing.md • administration/management/Back_up_and_restore.md • administration/management/Maintenance.md • administration/management/monitoring/Performance_tuning.md • administration/management/monitoring/Profiling.md • administration/management/monitoring/Slow_query_analysis.md • administration/management/monitoring/Troubleshooting.md • administration/management/monitoring/Resource_usage.md • administration/management/monitoring/Workload_analysis.md • administration/management/monitoring/Metric_reference.md • administration/management/monitoring/Audit_log.md • administration/management/monitoring/Query_log.md • administration/management/monitoring/Slow_query_log.md • administration/management/monitoring/BE_log.md • administration/management/monitoring/FE_log.md • administration/management/monitoring/Log_configuration.md • administration/management/monitoring/Diagnostic_tools.md • administration/management/monitoring/Support_bundles.md • administration/management/monitoring/Reporting.md • administration/management/monitoring/Integration.md • administration/management/monitoring/Grafana_dashboards.md • administration/management/monitoring/Prometheus_integration.md • administration/management/monitoring/ELK_integration.md • administration/management/monitoring/Slack_notifications.md • administration/management/monitoring/Email_notifications.md • administration/management/monitoring/Webhook_notifications.md • administration/management/monitoring/PagerDuty_integration.md
r
@Rocky 특정 쿼리만 datacache 안쓰게하려면?
r
특정 쿼리에서만 Data Cache(데이터 캐시) 기능을 사용하지 않으려면
enable_scan_datacache
세션 변수를 쿼리 힌트(Hint) 형태로 사용하거나, 해당 쿼리 실행 직전에 세션 설정을 변경하면 됩니다. StarRocks의 Data Cache는 주로 내장 스토리지(Shared-data 모드)나 외부 테이블(HDFS, S3 등) 스캔 시 성능을 높이기 위해 사용됩니다. 방법 1: 쿼리 힌트(Hint) 사용 (가장 추천) 쿼리 문장 안에 직접 설정을 삽입하여 해당 쿼리 하나에만 적용하는 방식입니다. 별도의 세션 복구가 필요 없어 가장 깔끔합니다.
Copy code
sql
SELECT /*+ SET_VAR(enable_scan_datacache = false) */ 
    * 
FROM your_external_table 
WHERE id = 100;
방법 2: 세션 변수 일시 변경 쿼리를 실행하기 전에 세션 수준에서 캐시를 끄고, 실행 후 다시 켜는 방법입니다.
Copy code
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.md
r
@Rocky starrocks 에서 특정 cn 노드 하나만 메모리를 점유하고 있는데, 실제로는 그렇게 많이 사용하고 있지 않음 show proc '/compute_nodes' 할때 DataCacheMetrics 가 그 cn 노드만 NA 로 보이는게 원인인걸까
r
StarRocks의
SHOW 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단계: 메모리 세부 정보 확인 실제로 어떤 모듈이 메모리를 점유하는지 쿼리로 확인합니다.
Copy code
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.md
r
@Rocky starrocks 에서 특정 cn 노드 하나만 메모리를 점유하고 있는데, 실제로는 그렇게 많이 사용하고 있지 않음 show proc '/compute_nodes' 할때 DataCacheMetrics 가 그 cn 노드만 NA 로 보이는게 원인인걸까 mem_Tracker 로 확인해볼땐, 정상이거든. prometheus metric으로 확인할때 점유하고 있는걸로 보임.
r
특정 CN(Compute Node) 하나에서만 *`DataCacheMetrics`가 `NA`*로 보이고, *Prometheus 지표와
mem_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` 디렉토리를 삭제*합니다.
Copy code
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.md
r
@Rocky starrocks 에서 특정 cn 노드 하나만 메모리를 점유하고 있는데, 실제로는 그렇게 많이 사용하고 있지 않음 show proc '/compute_nodes' 할때 DataCacheMetrics 가 그 cn 노드만 NA 로 보이는게 원인인걸까 mem_Tracker 로 확인해볼땐, 정상이거든. prometheus metric으로 확인할때 점유하고 있는걸로 보임. running query 0 mempctuesd 0 datacachemetric na cpuusedpct 0% 상태임.
r
네, 사용자가 겪고 계신 현상은 StarRocks의 *Data Cache(Block Cache) 모듈의 비정상 상태 및 메타데이터 메모리 누수*와 관련된 전형적인 증상입니다. `SHOW PROC '/compute_nodes'`에서 특정 노드의 `DataCacheMetrics`가 *`NA`*로 뜨는 것은 해당 노드의 캐시 모듈이 정상적으로 초기화되지 않았거나 어떤 이유로 중단되었음을 의미하며, 이것이 메모리 점유의 핵심 원인일 가능성이 매우 높습니다. 1. 현상 분석 * DataCacheMetrics: NA: 해당 CN 노드의 Data Cache 서비스가 FE와 통신하지 못하거나, 내부 에러로 인해 상태 보고를 멈춘 상태입니다. * Prometheus vs mem_tracker 차이: `mem_tracker`는 StarRocks의 쿼리 실행기 등이 사용하는 메모리를 추적하지만, Data Cache의 *메타데이터(starlet/fslib)*는 별도의 영역에서 관리됩니다. 특히 특정 버전에서는 이 메타데이터가 `mem_tracker`에 집계되지 않으면서 OS 수준의 Resident Memory(Prometheus 지표)만 계속 점유하는 버그가 있습니다. * Running Query 0, CPU 0%: 쿼리가 수행되지 않음에도 메모리만 높다면, 이는 실행 중인 작업 때문이 아니라 이미 할당된 *캐시 메타데이터가 메모리에서 해제되지 않고 고립*된 상태임을 시사합니다. 2. 근본 원인 (알려진 버그) StarRocks v3.1.8 이하 또는 v3.2.3 이하 버전에서 발생하는 Data Cache 메타데이터 메모리 누수 이슈입니다. 캐시 모듈이 비정상 종료되거나 초기화에 실패했음에도 불구하고, 이미 로드된 메타데이터가 메모리를 과도하게 점유하는 현상입니다. 3. 해결 방법 (조치 순서) 가장 확실하고 빠른 해결책은 해당 노드의 캐시 메타데이터를 초기화하고 재시작하는 것입니다. 1. CN 노드 중지
Copy code
bash
    # 해당 CN 노드의 프로세스를 중지합니다.
2. 문제가 되는 메타데이터 디렉토리 삭제 `cn.conf`에 설정된 캐시 경로(보통
storage_root_path
하위)에서 다음 폴더를 완전히 삭제합니다. 이 작업은 실제 캐시 데이터가 아닌 인덱스 정보만 삭제하므로 안전하며, 재시작 시 자동으로 재생성됩니다.
Copy code
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.md
r
@Rocky fe 가 cn 의 리포트를 못받고 있는데, 그 현상을 확인할 수 있는 방법은 ? cn 내에서 어떤 로그를 봐야하는가
r
CN 노드가 FE에 상태 리포트를 제대로 보내지 못하고 있거나, FE가 이를 인지하지 못하는 상황을 확인하려면 다음의 로그와 지표들을 점검해야 합니다. 1. CN 노드 로그 점검 (가장 직접적인 방법) CN 노드의 설치 경로 내
log/
디렉토리에서
<http://cn.INFO|cn.INFO>
(또는
<http://be.INFO|be.INFO>
) 파일을 확인합니다. * 하트비트(Heartbeat) 확인: FE와 CN 간의 기본 연결 상태를 확인합니다. 아래 키워드로 검색했을 때 주기적인 로그가 찍혀야 합니다.
Copy code
bash
    grep "heartbeat" log/cn.INFO | tail -n 20
*
get heartbeat from FE
같은 메시지가 없거나 에러가 있다면 네트워크 또는 FE 주소 설정 문제입니다. * 리포트(Report) 전송 확인: CN은 자신의 상태(Tablet, Metrics 등)를 주기적으로 Master FE에 리포트합니다. 리포트 실패 시 보통
thrift
관련 에러가 발생합니다.
Copy code
bash
    grep -E "report|thrift|Master" log/cn.INFO | grep -i "fail"
*
fail to report to Master FE
혹은
RPC error
등이 발견된다면 통신 상의 문제입니다. * Data Cache 모듈 상태 확인: `DataCacheMetrics`가 `NA`라면 캐시 모듈 자체의 초기화 실패를 의심해야 합니다.
Copy code
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 상세 상태 확인:
Copy code
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 리포트 수신 로그:
Copy code
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.md
r
@Rocky shared data 에서 connector scan pool 이뭐야?
r
StarRocks의 Shared-data(공유 스토리지/스토리지 컴퓨트 분리) 아키텍처와 관련하여 *Connector Scan Pool*은 외부 데이터나 외부 스토리지에 있는 데이터를 병렬로 읽어오기 위해 사용하는 *전용 스레드 풀(Thread Pool)*을 의미합니다. 주요 개념과 역할은 다음과 같습니다. 1. 역할: 외부 데이터 스캔 전용 스레드 StarRocks에는 크게 두 가지 스캔 엔진이 있습니다. * Olap Scan Pool (
pip_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): 현재 시스템에서 커넥터 스캔 스레드가 어떻게 작동하는지 확인할 수 있습니다.
Copy code
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.md
r
@Rocky how to disable datacache? and if i disable datacache mem, what happened for datacache disk?
r
To disable Data Cache and understand the impact of disabling its memory component, follow the guide below: 1. How to Disable Data Cache There are two ways to disable Data Cache depending on whether you want a partial or total shutdown. * Total Disable (Memory + Disk): Add the following parameter to your
be.conf
or
cn.conf
and restart the node:
Copy code
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:
Copy code
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:
Copy code
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.md
r
@Rocky Starrocks cache hit 되고있는걸 보려면 어떤 메트릭으로 어떻게 봐야해? cache 가 disk 도 있고 mem 도 있잖아.
r
StarRocks에서 Data Cache(Block Cache)의 히트율은 SQL 명령, Query Profile, 그리고 Prometheus 메트릭 세 가지 방법으로 확인할 수 있습니다. StarRocks는 보통 메모리를 L1 Cache, 디스크를 *L2 Cache*로 분류하여 관리합니다. 1. SQL을 통한 실시간 확인 (
SHOW PROC
)
가장 간단하게 전체 노드의 캐시 상태를 확인하는 방법입니다.
Copy code
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) 특정 쿼리가 실행될 때 캐시를 얼마나 썼는지 상세히 분석할 때 사용합니다.
Copy code
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.md
r
@Rocky Starrocks 4.1.1 에서 쿼리 타임아웃 설정하는게 session 변수로 query_timeout 맞아? 1200 초로 설정해뒀는데 show running queries 에서 보이는 QueryTimeout 시간이랑 다른데?
r
네, StarRocks 4.1.1 버전에서도 *`query_timeout`*은 세션 변수(Session Variable)가 맞습니다. (기본 단위: 초) 사용자께서 1,200초로 설정했음에도 불구하고 `SHOW RUNNING QUERIES`에서 보이는
QueryTimeout
값이 기대와 다른 이유는 크게 세 가지 가능성이 있습니다. 1. 리소스 그룹(Resource Group)의 타임아웃 제한 StarRocks의 리소스 그룹 기능이 활성화되어 있다면, 쿼리 타임아웃은 *"세션 변수(
query_timeout
) 값"*과 "리소스 그룹에 설정된
query_timeout
값"
중 *더 작은 값*으로 최종 결정됩니다. * 만약 소속된 리소스 그룹의 타임아웃이 300초(5분)로 설정되어 있다면, 세션에서 1,200초로 늘려도 리소스 그룹의 설정값이 우선 적용됩니다. * 확인 방법:
Copy code
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.md
r
@Rocky 세션변수로 쿼리 타임아웃이 1200초, 큐 펜딩 타임아웃이 6000초로 설정되어 있는데 쿼리가 1200초가 지나도 안끝날 수가 있나?
r
네, StarRocks 4.1.1 버전에서는 설정하신 조건에 따라 쿼리가 시작된 지 1200초가 넘어도 종료되지 않는 상황이 발생할 수 있습니다. 주요 원인은 크게 두 가지입니다. 1.
INSERT
,
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.md
r
@Rocky 다중사용자가 하나의 리소스그룹을 쓰고 있는데, 쿼리당 Fragment 수 제한 대규모 쿼리를 제한하는 가이드. 만약 문제의 쿼리를 발견했으면 Explain에서 어떤 값을 찾아서 기준으로 삼아야되는지 확인
r
StarRocks에서 여러 사용자가 하나의 리소스 그룹(Resource Group)을 공유할 때, 특정 사용자의 대규모 쿼리가 전체 자원을 점유하지 않도록 제한하는 방법과 `EXPLAIN`에서 확인해야 할 기준점을 정리해 드립니다. 1. 대규모 쿼리 제한 가이드 (리소스 그룹 설정) StarRocks에는 "Fragment 개수"를 직접 숫자로 제한하는 설정값은 없으나, 대규모 쿼리 차단(Circuit Breaker) 기능을 통해 쿼리의 복잡도와 자원 소모량을 효과적으로 제한할 수 있습니다. 리소스 그룹 생성 또는 수정 시 아래의 *`big_query_*`* 파라미터를 설정하세요: *
big_query_scan_rows_limit
(가장 추천):
한 쿼리가 스캔할 수 있는 최대 행(Rows) 수입니다. Fragment가 많아지는 복잡한 쿼리는 보통 대량의 데이터를 스캔하므로, 이 값을 설정하면 효과적입니다. * `big_query_cpu_second_limit`: 한 쿼리가 사용할 수 있는 최대 CPU 시간(초)입니다. Fragment 간의 데이터 이동(Shuffle)과 연산이 복잡할수록 CPU 사용량이 늘어나므로 이를 통해 제어 가능합니다. * `big_query_mem_limit`: 한 쿼리가 각 BE 노드에서 사용할 수 있는 최대 메모리(Bytes)입니다. * `concurrency_limit`: 해당 리소스 그룹 전체에서 동시에 실행될 수 있는 쿼리 수를 제한하여 자원 고갈을 방지합니다. 설정 예시 (SQL):
Copy code
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 References
r
@Rocky fe 에서 ANanlyze task 한도인 100개가 꽉차서 처리를 못할경우 그 쿼리는 어떻게되는가, query_timeout이 지나면 취소되는건가
r
FE(Frontend)에서
ANALYZE
태스크(통계 수집 작업) 대기 큐(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.md
r
@Rocky query_mem_limit 세션변수가 헤비쿼리가 동작할때 메모리를 admission해줄때 어떻게 동작하는지 알려줘
r
query_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.md
r
@Rocky 노드가 100대라면 쿼리 하나가 사용할 수 있는 메모리제한방법과 노드당 쿼리메모리한도 정하는 방법과 connector_scanner 가 사용할 수 있는 메모리는 query_mem_limit을 따르는가?
r
노드가 100대인 대규모 클러스터 환경에서 메모리를 제어하는 방법과 `connector_scanner`의 동작 방식에 대해 답변해 드립니다. 1. 100대 노드 환경에서 쿼리 메모리 제한 방법 StarRocks에서 쿼리 메모리 제한은 기본적으로 "노드당(Per-node)" 기준입니다. * 동작 원리: StarRocks는 Shared-nothing 아키텍처이므로, 특정 쿼리가 클러스터 전체에서 사용하는 총합을 제한하는 전역 변수는 없습니다. 대신 각 BE(Backend) 노드에서 개별적으로 메모리 사용량을 감시합니다. * 총 사용량 계산: 만약 `query_mem_limit`을 *10GB*로 설정하고 노드가 *100대*라면, 해당 쿼리는 이론적으로 클러스터 전체에서 최대 *1TB(10GB * 100)*의 메모리를 점유할 수 있습니다. * 설정 방법:
Copy code
sql
    -- 현재 세션에만 적용
    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.md