http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> session variables for page cache an...
# questions-and-troubleshooting
r
@Rocky session variables for page cache and datacache for memory
r
In StarRocks, there are several session variables and BE configurations used to manage the Page Cache (for local OlapTables) and Data Cache (for external storage/Data Lake). 1. Page Cache (Local Storage) Page Cache is used to cache data blocks from local StarRocks tables in memory. * Session Variables: * 
use_page_cache
(v3.2.0+): Controls whether a query should use the backend page cache. Default is 
true
. * 
skip_page_cache
(v3.3.9+): When set to 
true
, the query bypasses the page cache to avoid "polluting" the cache with large, one-time scan data. * BE Configurations (Memory Limits): * `storage_page_cache_limit`: Sets the maximum memory size for the storage page cache (e.g., 
20G
or 
20%
). * `disable_storage_page_cache`: Globally enables or disables the page cache. 2. Data Cache (External Storage / Data Lake) Data Cache accelerates queries on external tables (like HDFS or S3) and consists of a memory layer and a disk layer. * Session Variables: * `enable_scan_datacache`: Enables or disables the Data Cache feature for the current session. (Formerly 
enable_scan_block_cache
in versions prior to 3.2). * 
populate_datacache_mode
(v3.3.2+): Controls how data is cached during a read. Options are 
auto
(default), 
always
, or 
never
. * 
skip_local_disk_cache
(v3.3.9+): Instructs the backend to bypass the local disk cache for the session. * BE Configurations (Memory Limits): * `datacache_mem_size`: Sets the maximum memory limit for Data Cache. This memory is used for the "Page Cache" component of the Data Cache feature. * `datacache_enable`: The global switch for the Data Cache feature. 3. Query Cache (Result Cache) Often confused with Page Cache, the Query Cache stores the final results of sub-computations. * Session Variables: * `enable_query_cache`: Enables the query result cache. * 
query_cache_entry_max_bytes
/ `query_cache_entry_max_rows`: Thresholds for when to cache or bypass results. * BE Configuration: * `query_cache_capacity`: The total memory capacity allocated for the query result cache on each BE (default is 512MB). Summary Table Cache Type | Session Toggle | Memory Limit (BE Config) Local Page Cache | 
use_page_cache
| 
storage_page_cache_limit
External Data Cache | 
enable_scan_datacache
| 
datacache_mem_size
Query Result Cache | 
enable_query_cache
| 
query_cache_capacity
Note: You cannot set the absolute memory size limits (like "10GB") via session variables; these must be configured in the 
be.conf
file or via 
UPDATE be_configs
for dynamic adjustment. References • administration/management/BE_configuration.md • sql-reference/System_variable.md • administration/management/resource_management/Memory_management.md • data_source/data_cache.md • administration/management/monitoring/metrics.md • using_starrocks/caching/query_cache.md
r
@Rocky starrocks 의 부하테스트를 위한 가이드라인이 있나
r
StarRocks의 부하 테스트(Benchmark)를 위한 공식 가이드라인과 권장 방법론은 다음과 같습니다. StarRocks는 주로 *SSB(Star Schema Benchmark)*와 TPC-H/TPC-DS 표준 벤치마크를 사용하여 성능을 측정합니다. 1. 주요 테스트 유형 부하 테스트 시 다음 세 가지 관점을 주로 확인합니다: * 쿼리 응답 시간(Latency): 단일 쿼리가 얼마나 빨리 수행되는지 측정. * 동시성(Concurrency/QPS): 여러 사용자가 동시에 쿼리를 보낼 때 시스템이 초당 몇 개의 쿼리를 처리하는지 측정. * 데이터 로딩 속도(Throughput): 대량의 데이터를 얼마나 빠르게 수집(Ingestion)할 수 있는지 측정. 2. 표준 벤치마크 도구 및 데이터셋 StarRocks는 성능 비교를 위해 다음 데이터셋 사용을 권장하며, 이를 위한 도구를 제공합니다. * SSB (Star Schema Benchmark): OLAP 성능 테스트의 표준입니다. 특히 StarRocks는 이를 단일 와이드 테이블로 변환한 SSB Flat 테스트에서 매우 높은 성능을 보입니다. * TPC-H / TPC-DS: 복잡한 Join과 분석 쿼리가 포함된 표준 벤치마크입니다. * StarRocks 공식 벤치마크 툴 (GitHub): 데이터 생성(
dbgen
), 테이블 생성(DDL), 데이터 로딩(
Stream Load
), 쿼리 실행을 자동화하는 스크립트를 제공합니다. 3. 부하 테스트 수행 단계 1. 환경 구성: 테스트 목적에 맞는 BE(Backend)와 FE(Frontend) 노드 수를 구성합니다. (최소 BE 3대 권장) 2. 데이터 생성 및 로딩: * 
gen_data
스크립트로 데이터를 생성합니다. * Stream Load 방식을 사용하여 데이터를 로딩하는 것이 가장 빠르며 권장됩니다. 3. 쿼리 실행: * Cold Run: 캐시가 없는 상태에서의 첫 실행 속도 측정. * Hot Run: 캐시(Page Cache 등)가 활성화된 상태에서 3~5회 반복 실행 후 평균값 측정. 4. 동시성 테스트: 
mysqlslap
또는 `Apache JMeter`와 같은 표준 도구를 사용하여 10, 20, 50개 등 동시 스레드를 늘려가며 QPS와 P99 Latency를 확인합니다. 4. 용량 산정 및 모니터링 가이드 (Tip) 부하 테스트 중 성능 병목을 확인하기 위해 다음을 모니터링해야 합니다: * CPU 계산식: StarRocks는 코어당 초당 약 1,000만~1억 개의 행을 처리하는 것을 목표로 설계되었습니다. _ 
필요 CPU 코어 수 = (스캔 행 수 / 코어당 처리 행 수) / 목표 응답 시간 _ 예상 QPS
* Grafana 대시보드: StarRocks용 Grafana 템플릿을 사용하여 BE의 CPU 사용률, 메모리(Page Cache), 쿼리 큐 대기 시간 등을 실시간으로 확인하십시오. * Query Profile: 특정 쿼리가 느리다면 
EXPLAIN ANALYZE
명령어나 FE 감사 로그(Audit Log)를 통해 병목 지점을 분석합니다. 5. 테스트 시 주의사항 * 자원 격리: 테스트 환경에서 Resource Group을 사용하여 테스트 쿼리가 다른 작업에 영향을 주지 않도록 설정할 수 있습니다. * 데이터 스케일: 최소 100GB(SF100) 이상의 데이터를 사용하여 실제 운영 환경과 유사한 부하를 주어야 StarRocks의 분산 처리 성능이 정확히 측정됩니다. 공식 문서의 Benchmarks 섹션에서 상세한 단계별 튜토리얼을 확인할 수 있습니다. References • loading/loading_introduction/troubleshooting_loading.md • administration/management/BE_configuration.md • faq/resource_isolation_faq.md
r
@Rocky starrock_be_pipe_connector_scan_running_tasks 보니까 특정 노드만 값이 보이는데 우리는 150개의 노드인데 몇개 노드만 값이 있는 이유는뭐야? 나머지는 다 0임
r
starrocks_be_pipe_connector_scan_running_tasks
메트릭이 일부 노드에서만 나타나고 나머지 노드에서는 0으로 보이는 현상은 StarRocks의 Pipe 엔진 및 커넥터(External Table/Pipe)의 태스크 스케줄링 방식 때문입니다. 150대의 대규모 클러스터에서 특정 노드만 일을 하고 있는 이유는 크게 다음과 같은 원인으로 압축됩니다. 1. 처리해야 할 파일(또는 태스크) 개수의 부족 StarRocks의 Pipe(또는 
COPY INTO
, Catalog 기반 외부터블 조회)는 데이터를 여러 개의 Morsel(데이터 조각) 단위로 쪼개어 처리합니다. * 만약 로딩하거나 쿼리하려는 외부 파일의 개수가 적거나 데이터 크기가 작으면, FE(Frontend)는 이를 150대 전체로 퍼뜨리지 않고 효율성을 위해 *일부 노드에만 할당*합니다. * 예를 들어, 읽어야 할 파일이 10개뿐이라면 최대 10개의 노드(또는 그 미만)에서만 스캔 태스크가 실행됩니다. 2. 병렬도(Concurrency) 및 스케줄링 설정 StarRocks는 시스템 자원의 과도한 사용을 막기 위해 한 번에 실행되는 스캔 태스크의 수를 제어합니다. * 
connector_io_tasks_per_scan_operator
: 기본적으로 한 스캔 연산자당 할당되는 I/O 태스크 수가 제한되어 있습니다. * 
pipeline_dop
(Degree of Parallelism): 쿼리나 로드 시 설정된 병렬도가 낮으면 전체 노드를 골고루 사용하지 않고 일부 노드의 스레드만 점유하게 됩니다. 3. 리소스 그룹(Resource Group) 및 워크로드 격리 만약 Resource Group 기능을 사용하여 특정 Pipe 작업이나 쿼리를 특정 노드군으로 제한했다면, 해당 그룹에 속하지 않은 노드들은 태스크를 받지 않으므로 메트릭이 0으로 표시됩니다. 4. 데이터 Locality (HDFS 등의 경우) 외부 저장소가 HDFS인 경우, StarRocks는 가급적 데이터가 물리적으로 존재하는 노드(DataNode와 BE가 같은 위치일 때)에서 스캔을 수행하려고 시도합니다. 특정 데이터가 일부 노드에 몰려 있다면 해당 노드들 위주로 `running_tasks`가 발생할 수 있습니다. (S3 같은 객체 스토리지의 경우에는 이 영향이 거의 없습니다.) 5. Pipe 객체의 특성 (
CREATE PIPE
) 만약 `CREATE PIPE`를 통한 지속적 인입 작업을 보고 계신 것이라면: * Pipe는 내부적으로 Micro-batch 방식으로 작동합니다. * 큐에 쌓인 파일들을 순차적으로 처리하면서 특정 시점에는 소수의 BE 노드만 선택되어 스캔을 수행하는 스케줄링 알고리즘을 가질 수 있습니다. 150대 노드 전체가 동시에 하나의 인입 작업을 분담하기보다는, 필요한 만큼의 노드만 활성화되는 방식입니다. ────────── 확인해볼 사항 * 파일 개수 확인: 읽어들이는 소스 데이터의 파일 개수가 150개 이상으로 충분히 많은지 확인해 보세요. * 시스템 변수 확인:
Copy code
sql
    SHOW VARIABLES LIKE '%pipeline_dop%';
    SHOW VARIABLES LIKE '%connector_io_tasks_per_scan_operator%';
* Profile 확인: 실행 중인 쿼리나 로드 작업의 *Query Profile*을 확인하면 실제로 어느 노드에 몇 개의 인스턴스가 할당되었는지(Fragment Instance 분포)를 정확히 파악할 수 있습니다. 결론적으로, 데이터 규모나 설정된 병렬도가 150대 전체를 풀가동할 만큼 크지 않다면 일부 노드만 값이 보이는 것은 *StarRocks의 정상적인 리소스 최적화 결과*일 가능성이 매우 높습니다. References • sql-reference/System_variable.md • administration/management/monitoring/metrics.md • loading/hdfs_load.md • administration/management/resource_management/Load_balance.md • administration/management/resource_management/Replica.md • loading/Kafka-connector-starrocks.md • knowledge/usage/best-practice.md • loading/Flink-connector-starrocks.md • loading/loading_introduction/troubleshooting_loading.md References • administration/management/resource_management/Load_balance.md • loading/Kafka-connector-starrocks.md • knowledge/usage/best-practice.md • administration/management/resource_management/Replica.md • loading/Flink-connector-starrocks.md • loading/hdfs_load.md
r
@Rocky pipe_connector_scan_pending_tasks 와 running tasks 가 뭔지? 왜 전체 노드에서 특정 노드만 tasks 값이 보이지 ?
r
`pipe_connector_scan_running_tasks`와 `pipe_connector_scan_pending_tasks`는 StarRocks의 *커넥터(Connector) 프레임워크*를 통해 외부 데이터(S3, HDFS 등)를 스캔할 때 발생하는 지표입니다. 1. 지표의 의미 * 
pipe_connector_scan_running_tasks
(실행 중인 태스크) * 현재 BE(Backend) 노드의 커넥터 전용 스레드 풀에서 실제로 실행 중인 스캔 태스크의 개수입니다. * 이 값이 높으면 해당 노드가 외부 데이터를 읽어오느라 바쁘게 일하고 있다는 뜻입니다. * 
pipe_connector_scan_pending_tasks
(대기 중인 태스크) * BE 노드에 할당은 되었지만, 스레드 풀이 가득 차서 큐에서 대기 중인 태스크의 개수입니다. * 이 값이 지속적으로 높다면 스캔 성능 병목이 발생하고 있음을 의미하며, BE의 커넥터 스레드 수(
connector_io_tasks_per_scan_operator
) 설정을 조정해야 할 수도 있습니다. ────────── 2. 왜 150개 노드 중 특정 노드만 값이 보일까? 150대의 대규모 클러스터에서 일부 노드만 일을 하고 나머지가 0인 이유는 크게 세 가지 효율화 전략 때문입니다. ① 데이터 지역성 및 해시 스케줄링 (Data Locality & Hashing) StarRocks는 Data Cache(데이터 캐시) 효율을 높이기 위해, 특정 파일이나 데이터 블록을 가급적 *이전에 처리했던 노드에 우선 할당*합니다. * 동일한 외부 파일은 파일 경로의 해시 값을 기반으로 특정 BE 노드들에 고정되어 할당되는 경향이 있습니다. * 만약 스캔 대상 데이터가 클러스터 전체 노드 수(150대)보다 적은 수의 파일로 구성되어 있다면, 해당 파일들을 담당하는 특정 노드들만 지표가 올라가고 나머지는 0이 됩니다. ② 쿼리 병렬도 (Pipeline DOP) 설정 쿼리 실행 시 설정된 병렬도(
pipeline_dop
)가 노드 수에 비해 낮을 경우 발생합니다. * 예를 들어, 150대 노드가 있더라도 쿼리의 총 태스크 조각(Morsels/Splits)이 20개뿐이라면, FE는 이 20개를 150대에 골고루 뿌리기보다 20대의 노드에 집중시켜 네트워크 오버헤드를 줄입니다. ③ 소량의 데이터 인입 (Pipe/Copy Into) 
PIPE
객체를 통해 데이터를 지속적으로 가져오는 경우, 한 번에 처리하는 데이터 양(Micro-batch)이 150대 노드를 모두 사용할 만큼 크지 않을 수 있습니다. * 데이터 인입 작업은 시스템 자원을 효율적으로 쓰기 위해 최소한의 노드만 사용하여 작업을 완료하려는 성질이 있습니다. 요약 및 확인 방법 * 정상 여부: 일부 노드만 값이 찍히더라도 전체적인 쿼리 성능이나 데이터 로딩 속도에 문제가 없다면, 이는 StarRocks가 *캐시 효율과 네트워크 비용을 고려해 지능적으로 태스크를 분배*하고 있는 정상적인 상태입니다. * 확인 팁: 
SHOW PROC '/current_queries';
명령어로 현재 실행 중인 쿼리를 찾은 뒤, *Query Profile*을 확인해 보세요. 
ScanNode
항목에서 데이터가 특정 노드에 몰려 있는지(Skew), 아니면 태스크 수 자체가 적은 것인지 상세히 확인할 수 있습니다. References • administration/management/monitoring/metrics.md • sql-reference/System_variable.md • data_source/data_cache.md • administration/management/resource_management/Load_balance.md • administration/management/BE_configuration.md
r
@Rocky 대규모 환경에서 CN이 골고루 사용되고 있는 걸 보기 위한 메트릭 알려줘
r
150대와 같은 대규모 환경에서 CN(Compute Node)이 균형 있게 자원을 사용하고 있는지 확인하려면, *노드별 편차(Skew)*를 시각화하는 것이 핵심입니다. Grafana 대시보드에서 각 노드별로 다음 메트릭들을 나열하여 비교해 보시기 바랍니다. 1. CPU 및 시스템 자원 균형 (가장 직접적인 지표) CN은 연산 전용 노드이므로 CPU 사용률이 가장 중요한 지표입니다. * 
starrocks_be_cpu_usage
: 각 노드의 CPU 사용률입니다. 특정 노드만 높다면 쿼리 플랜이 특정 노드에 집중되거나 데이터 스큐(Skew)가 있는 것입니다. * 
starrocks_be_memory_allocated_bytes
: 노드별 메모리 할당량입니다. 대규모 Join이나 집계 작업이 특정 노드에 쏠리는지 확인합니다. 2. 쿼리 실행 및 태스크 분배 (Pipeline Engine) StarRocks의 파이프라인 엔진이 태스크를 어떻게 배분하는지 보여줍니다. * 
starrocks_be_pipeline_executor_running_tasks
: 현재 실행 중인 파이프라인 태스크 수입니다. 모든 CN에서 이 숫자가 유사하게 유지되어야 합니다. * 
starrocks_be_pipeline_driver_queue_len
: 실행을 대기 중인 큐의 길이입니다. 특정 노드에서만 이 값이 높다면 해당 노드가 병목(Straggler)이 되고 있다는 신호입니다. 3. 데이터 스캔 및 I/O 균형 (Connector/External Table) S3나 HDFS 같은 외부 데이터를 읽을 때의 부하 분산 지표입니다. * 
starrocks_be_pipe_connector_scan_running_tasks
: 질문하신 지표로, 현재 외부 데이터를 읽고 있는 스캔 태스크 수입니다. * 
starrocks_be_query_scan_bytes_total
: 노드별로 읽어들인 누적 데이터 양입니다. 150대 노드가 각각 비슷한 양의 바이트를 처리하고 있는지 확인하세요. 4. 데이터 캐시 효율 (Shared-Data 환경 핵심) CN 환경에서는 로컬 디스크에 외부 데이터를 캐싱합니다. 캐시가 골고루 쌓여야 성능이 균일해집니다. * 
starrocks_be_data_cache_read_bytes_total
: 캐시에서 읽어온 데이터 양입니다. * 
starrocks_be_data_cache_cache_size
: 각 노드가 현재 사용 중인 캐시 용량입니다. 특정 노드만 캐시를 많이 쓴다면 데이터 접근 패턴이 편향된 것입니다. 5. 연결 및 네트워크 * 
starrocks_be_connection_total
: FE가 각 CN으로 연결을 골고루 분산하고 있는지 확인합니다. * 
starrocks_be_network_send_bytes_total
/ 
receive_bytes_total
: 노드 간 데이터 셔플링(Shuffle) 시 발생하는 네트워크 부하가 균등한지 측정합니다. ────────── 💡 팁: SQL로 빠르게 확인하기 대시보드 외에 SQL 창에서 전체적인 상태를 요약해서 보고 싶을 때는 다음 명령어를 사용하세요:
Copy code
sql
-- 모든 CN의 CPU, 메모리, 실행 중인 쿼리 수를 한눈에 확인
SHOW COMPUTE NODES;
이 결과에서 
NumRunningQueries
, 
CpuUsedPct
, 
MemUsedPct
컬럼을 비교하여 150개 노드의 수치가 크게 차이 나지 않는지 점검하시면 됩니다. 만약 특정 노드만 계속 일을 한다면? 1. Data Skew: 특정 파티션이나 컬럼 값에 데이터가 몰려 있어 특정 노드가 담당할 분량이 많은 경우. 2. Plan Skew: FE의 옵티마이저가 쿼리 계획을 세울 때 특정 노드 위주로 인스턴스를 할당한 경우 (주로 데이터 소스 파일 수가 적을 때 발생). References • administration/management/monitoring/metrics.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md • administration/http_interface.md • data_source/data_cache.md References • administration/http_interface.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md • administration/management/monitoring/metrics.md
r
@Rocky memory of process exceed limit 에러 중 read and decompress page 랑 get chunk from scanner 에러에 대해서 설명해줘
r
이 에러들은 StarRocks의 BE(Backend) 프로세스가 설정된 전체 메모리 사용량(
mem_limit
)을 초과했을 때 발생하며, 구체적으로 어떤 작업을 하다가 한계에 도달했는지를 나타냅니다. 1. 
read and decompress page
 이 에러는 BE가 저장소(디스크 혹은 외부 저장소)에서 데이터를 읽어와 *압축을 해제하고 메모리에 올리는 과정*에서 발생합니다. * 상황: StarRocks는 데이터를 '페이지(Page)' 단위로 나누어 압축해 저장합니다. 쿼리 실행 시 이 페이지들을 읽어 메모리에서 압축을 풀어야 하는데, 이때 메모리 할당을 시도하다가 BE 전체 메모리 한도에 걸린 것입니다. * 주요 원인: * 컬럼이 너무 많은 경우: 한 번에 읽어야 할 컬럼(Wide Column)이 너무 많으면 압축 해제 시 필요한 메모리 양이 급격히 늘어납니다. * 대량의 Upsert 작업: Primary Key 모델에서 대량의 데이터를 업데이트(Upsert)할 때, 기존 데이터를 확인하기 위해 대량의 페이지를 읽고 해제하는 과정에서 메모리가 튈 수 있습니다. * 복잡한 데이터 타입: JSON이나 긴 문자열 컬럼이 포함된 페이지를 처리할 때 더 많은 메모리가 소모됩니다. 2. 
get chunk from scanner
 이 에러는 데이터를 스캔하는 'Scanner' 단계에서 읽어들인 데이터를 *'Chunk(연산 단위)'로 변환해 상위 연산자로 넘겨주려는 시점*에 발생합니다. * 상황: StarRocks의 실행 엔진은 데이터를 'Chunk'라는 단위로 묶어서 처리합니다. Scanner가 디스크에서 읽은 데이터를 이 Chunk 구조로 만들어 메모리에 담아두는데, 이 Chunk들이 차지하는 메모리가 한도를 넘어선 것입니다. * 주요 원인: * 높은 스캔 병렬도: 너무 많은 스캔 스레드가 동시에 실행되어 각 스레드가 들고 있는 Chunk들이 메모리를 점유할 때 발생합니다. * 필터링(Predicate) 효율 저하: 조건절(Where절)에 의해 걸러지는 데이터가 적어 너무 많은 로우가 그대로 Chunk에 담겨 올라올 때 발생합니다. * Chunk 사이즈 설정: `vector_chunk_size`와 같은 설정에 따라 한 번에 처리하는 데이터 양이 큰데, 이를 처리할 BE 메모리가 부족한 경우입니다. ────────── 해결 및 대응 방법 1. 쿼리 단위 메모리 제한 확인: 특정 쿼리가 너무 많은 메모리를 쓰는 것이라면 
exec_mem_limit
세션 변수를 높여줄 수 있지만, 만약 *BE 전체 메모리 한도*(
Memory of process exceed limit
)에 걸린 것이라면 다음을 확인해야 합니다. 2. BE 메모리 한도(
mem_limit
) 조정: 서버의 물리 메모리에 여유가 있다면 `be.conf`에서 
mem_limit
(기본 90%) 값을 확인해 보세요. 3. 불필요한 컬럼 읽기 지양: 
SELECT *
보다는 필요한 컬럼만 선택하여 스캔 단계의 메모리 부하를 줄이세요. 4. Primary Key 테이블 최적화: Upsert 시 메모리가 튄다면 
enable_persistent_index
설정을 통해 인덱스가 메모리를 과하게 점유하지 않도록 설정할 수 있습니다. 5. 프로파일 확인: `get_query_profile`을 통해 어떤 ScanNode에서 메모리를 많이 쓰는지, 데이터 스큐(Skew)가 발생해 특정 노드에만 부하가 쏠린 것은 아닌지 확인이 필요합니다. 요약하자면, *`read and decompress page`*는 데이터를 읽는 *저수준 I/O 단계*의 메모리 부족이고, *`get chunk from scanner`*는 읽은 데이터를 *연산용 데이터 구조(Chunk)로 만드는 단계*의 메모리 부족입니다. References • faq/Sql_faq.md • administration/management/resource_management/Memory_management.md • administration/management/BE_configuration.md • knowledge/usage/best-practice.md • faq/loading/Loading_faq.md • sql-reference/System_variable.md • deployment/environment_configurations.md • administration/management/monitoring/alert.md • unloading/Flink_connector.md References • unloading/Flink_connector.md • knowledge/usage/best-practice.md • administration/management/BE_configuration.md • faq/Sql_faq.md • faq/loading/Loading_faq.md • administration/management/resource_management/Memory_management.md
r
@Rocky starrock be query scan pending 이 늘어나는 이유는 뭐야?
r
starrocks_be_query_scan_pending
(또는 
pipe_scan_executor_queuing
) 수치가 늘어나는 것은 BE 노드의 *데이터 스캔 전용 스레드 풀(Thread Pool)이 포화 상태*에 도달했음을 의미합니다. 즉, 데이터를 읽어오라는 요청(Scan Task)은 계속 들어오는데, 이를 처리할 수 있는 스레드가 부족하여 작업들이 *큐(Queue)에서 대기*하고 있는 상태입니다. 주요 원인은 다음과 같습니다. 1. I/O 병목 및 느린 저장소 (External Storage) * 원인: S3, HDFS 등 외부 저장소의 응답 속도가 느려지면, 스캔 태스크 하나가 완료되는 시간이 길어집니다. * 결과: 스레드 풀 내의 스레드들이 작업을 빨리 끝내고 반환되지 못하면서, 뒤따라오는 태스크들이 계속 큐에 쌓이게 됩니다. 2. 과도한 동시 쿼리 (High Concurrency) * 원인: 한꺼번에 너무 많은 사용자가 조회를 요청하거나, 대량의 병렬 쿼리가 실행될 때 발생합니다. * 결과: 각 쿼리마다 수많은 스캔 태스크를 생성하는데, 시스템이 정해둔 최대 스레드 수(
pipeline_scan_executor_thread_num
)를 초과하는 요청이 들어오면 대기 상태로 전환됩니다. 3. "Small File" 문제 (많은 수의 작은 파일) * 원인: 읽어야 할 파일의 크기는 작지만 개수가 수천~수만 개로 너무 많을 때 발생합니다. * 결과: 파일 하나를 읽을 때마다 태스크가 생성되는데, 실제 데이터를 읽는 시간보다 파일을 열고 닫는 오버헤드가 커지면서 스레드 풀을 비효율적으로 점유하게 됩니다. 4. 리소스 그룹(Resource Group) 제한 * 원인: 특정 리소스 그룹에 설정된 CPU나 병렬도 제한에 걸린 경우, 해당 그룹의 쿼리가 더 이상 스레드를 점유하지 못하도록 제어될 때 큐잉이 발생할 수 있습니다. 5. CPU 부하 (Heavy Computation) * 원인: 데이터를 읽어온 후 수행하는 필터링, 압축 해제(Decompress) 등의 작업이 CPU를 많이 소모할 때 발생합니다. * 결과: I/O 스레드가 데이터를 읽어도 CPU 자원을 할당받지 못해 처리가 지연되면, 전체적인 스캔 회전율이 떨어지며 펜딩이 발생합니다. ────────── 대응 및 확인 방법 1. 쿼리 프로파일 확인: 
SHOW PROC '/current_queries';
명령어로 실행 중인 쿼리의 Profile을 확인하세요. 특정 `ScanNode`에서 `WaitTime`이나 `ScanTime`이 비정상적으로 높은지 체크해야 합니다. 2. 저장소 상태 점검: 외부 테이블 스캔 중이라면 S3/HDFS의 Throttling이나 네트워크 지연이 있는지 확인하세요. 3. 설정 조정 (신중히 결정): BE의 스레드 수를 조정하여 처리 성능을 높일 수 있습니다. (서버 자원이 여유로울 때 권장) * `pipeline_scan_executor_thread_num`: 파이프라인 엔진의 스캔 스레드 수 (기본값은 CPU 코어 수에 비례) 4. Data Cache 활용: 반복적인 스캔이 문제라면 StarRocks의 Data Cache 기능을 활성화하여 원격 저장소 I/O 의존도를 낮추는 것이 가장 효과적입니다. References • administration/management/monitoring/metrics.md • administration/management/resource_management/query_queues.md • administration/management/BE_configuration.md • data_source/data_cache.md References • administration/management/monitoring/metrics.md • administration/management/resource_management/query_queues.md • administration/management/monitor_manage_big_queries.md • faq/Sql_faq.md
r
@Rocky 리소스그룹으로 쿼리별 메모리 제한 시 쿼리의 전체 메모리 사용 제한을 걸려면 big_query_meme_limit 을 걸어야 하나 Mem_limit 을 걸어야 하나?
r
리소스 그룹을 통해 *쿼리별(개별 쿼리) 메모리 사용량*을 제한하고 싶다면 *`big_query_mem_limit`*을 사용해야 합니다. 두 설정의 차이점은 다음과 같습니다. 1. 
mem_limit
(리소스 그룹 전체 제한) * 대상: 해당 리소스 그룹에 속한 모든 쿼리의 합계 메모리 사용량입니다. * 단위: 퍼센트(%, 예: `0.2`는 BE 쿼리 메모리 풀의 20% 의미). * 용도: 특정 업무용(예: 마케팅팀, 개발팀)으로 할당된 전체 리소스 파이를 제한할 때 사용합니다. 그룹 내의 쿼리들이 이 합계를 넘어가면 새로운 쿼리가 대기하거나 기존 쿼리가 실패할 수 있습니다. 2. 
big_query_mem_limit
(개별 쿼리 제한) * 대상: 해당 리소스 그룹에서 실행되는 *개별 쿼리 하나*가 사용할 수 있는 최대 메모리입니다. * 단위: 바이트(Byte, 예: `1073741824`는 1GB 의미). * 특징: * BE 노드당 기준: 이 제한은 각 BE 노드별로 적용됩니다. (전체 클러스터 합계가 아님에 주의) * 동작: 쿼리가 실행 중에 설정된 메모리 양을 초과하면 해당 쿼리는 즉시 종료(Terminated)됩니다. * 용도: 특정 사용자가 실수로 무거운 쿼리를 날려 시스템 전체가 느려지는 것을 방지하는 '가드레일' 역할을 합니다. ────────── 요약 및 권장 설정 쿼리 하나가 너무 많은 메모리를 쓰는 것을 막고 싶다면 다음과 같이 리소스 그룹을 설정하세요.
Copy code
sql
CREATE RESOURCE GROUP my_group
TO (user='bad_user')
WITH (
    "mem_limit" = "0.5",             -- 그룹 전체는 BE 메모리의 50%까지 사용 가능
    "big_query_mem_limit" = "2147483648" -- 하지만 개별 쿼리 하나는 노드당 2GB를 넘을 수 없음
);
참고: 리소스 그룹 설정 외에도 세션 변수인 `exec_mem_limit`을 통해서도 개별 쿼리 메모리를 제한할 수 있지만, 리소스 그룹을 사용하면 사용자나 데이터베이스 단위로 *강제적인 정책*을 적용하기에 더 적합합니다. References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • administration/management/resource_management/Memory_management.md References • faq/resource_isolation_faq.md • administration/management/resource_management/resource_group.md
r
@Rocky 리소스그룹으로 쿼리별 메모리 제한 시 쿼리의 전체 메모리 사용 제한을 걸려면 big_query_meme_limit 을 걸어야 하나 Mem_limit 을 걸어야 하나? 만약 특정 쿼리가 per node당 메모리 얼마 쓰는지 보려면 EXPLAIN ANALYZE에서 뭘 봐야하나 ?
r
리소스 그룹을 통해 *개별 쿼리*의 메모리 사용량을 제한하고 싶다면 *`big_query_mem_limit`*을 설정해야 합니다. 1. 
mem_limit
vs 
big_query_mem_limit
 * 
big_query_mem_limit
(개별 쿼리 제한): * 해당 리소스 그룹에서 실행되는 *쿼리 하나*가 각 BE(Backend) 노드에서 사용할 수 있는 최대 메모리입니다. * 쿼리가 실행 중에 이 한도를 넘어서면 "Memory exceed limit of resource group" 에러와 함께 즉시 종료됩니다. * 용도: 특정 쿼리가 시스템 전체의 메모리를 독점하는 것을 방지하는 가드레일 역할을 합니다. * 
mem_limit
(그룹 전체 제한): * 해당 리소스 그룹에 속한 *모든 쿼리들의 메모리 사용량 합계*를 제한합니다. (BE의 전체 쿼리 메모리 풀 대비 비율로 설정) * 용도: 워크로드 간(예: 실시간 대시보드 vs 배치 분석)의 리소스 간섭을 방지합니다. ────────── 2. `EXPLAIN ANALYZE`에서 노드당 메모리 확인하기 특정 쿼리가 각 BE 노드에서 메모리를 얼마나 썼는지 확인하려면 
EXPLAIN ANALYZE
결과(또는 Query Profile)에서 다음 항목들을 확인해야 합니다. 1. 
QueryPeakMemoryUsagePerNode
(전체 요약 섹션): * 해당 쿼리가 실행된 모든 노드 중, *가장 메모리를 많이 사용한 노드의 피크(Peak) 사용량*을 보여줍니다. `big_query_mem_limit`에 도달했는지 확인할 때 가장 먼저 봐야 할 지표입니다. 2. 
Top 10 nodes with the highest memory usage
(전체 요약 섹션): * 메모리를 가장 많이 점유한 상위 10개 노드의 리스트와 각각의 사용량을 보여줍니다. 특정 노드에만 부하가 쏠렸는지(Skew) 확인할 수 있습니다. 3. 
InstancePeakMemoryUsage
(Fragment 섹션): * 더 상세하게 들어가서 각 Fragment나 Instance 단위의 메모리 사용량을 보고 싶을 때 확인합니다. 특정 연산자(Join, Aggregate 등)가 메모리를 많이 쓰는지 파악할 때 유용합니다. 실행 방법 예시:
Copy code
sql
EXPLAIN ANALYZE SELECT ... ;
결과 텍스트의 상단 Summary 부분에서 
QueryPeakMemoryUsagePerNode
항목을 찾아보세요. 예를 들어 이 값이 `2.5GB`인데 `big_query_mem_limit`이 `2GB`로 설정되어 있었다면 해당 쿼리는 종료될 것입니다. References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • best_practices/query_tuning/query_profile_operator_metrics.md • best_practices/query_tuning/query_profile_text_based_analysis.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN_ANALYZE.md References • best_practices/query_tuning/query_profile_operator_metrics.md • best_practices/query_tuning/query_profile_text_based_analysis.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/sql-statements/cluster-management/plan_profile/ANALYZE_PROFILE.md • best_practices/query_tuning/query_profile_overview.md
r
@Rocky 쿼리날릴때 커스텀 쿼리 아이디 지정해서 사용하는법
r
StarRocks v3.4.0 버전부터 *`custom_query_id`*라는 시스템 변수를 통해 사용자 정의 쿼리 ID를 지정할 수 있는 기능이 추가되었습니다. 이 기능을 사용하면 외부 시스템의 트래킹 ID나 특정 태스크 ID를 StarRocks 쿼리에 바인딩하여, 나중에 감사 로그(Audit Log)나 프로세스 리스트에서 쉽게 추적하고 관리할 수 있습니다. 방법은 크게 두 가지가 있습니다. 1. 세션 변수 설정 (SET SESSION) 쿼리를 실행하기 전에 세션 수준에서 ID를 설정하는 방식입니다. 해당 쿼리가 종료되면 값은 자동으로 초기화됩니다.
Copy code
sql
-- 1. 커스텀 ID 설정
SET SESSION custom_query_id = 'my_unique_task_001';

-- 2. 쿼리 실행
SELECT * FROM my_table WHERE id = 10;
2. 쿼리 힌트 사용 (SET_VAR) 쿼리 문장 내에 직접 포함시키는 방식입니다. 이 방식은 해당 단일 쿼리에만 즉시 적용되므로 가장 권장되는 방법입니다.
Copy code
sql
SELECT /*+ SET_VAR(custom_query_id = 'my_unique_task_001') */ * 
FROM my_table 
WHERE id = 10;
────────── 활용 및 확인 방법 지정한 `custom_query_id`는 다음과 같이 활용할 수 있습니다. * 진행 중인 쿼리 확인: 
SHOW PROC '/current_queries'
명령어를 통해 현재 실행 중인 쿼리의 
CustomQueryId
컬럼에서 확인할 수 있습니다. * 쿼리 강제 종료: 일반적인 
QueryId
대신 사용자가 지정한 ID로 쿼리를 종료할 수 있습니다.
Copy code
sql
    KILL QUERY 'my_unique_task_001';
* 감사 로그 확인: FE의 
fe.audit.log
파일 내 
customQueryId
필드에 해당 값이 기록되어 사후 분석이 용이합니다. 주의사항: * 이 기능은 StarRocks v3.4.0 이상 버전에서만 지원됩니다. 이전 버전을 사용 중이라면 주석(Comment) 등을 활용해 로그에서 수동으로 찾는 방식 외에는 공식적인 ID 바인딩 기능이 없습니다. References • sql-reference/System_variable.md • using_starrocks/running_queries.md • best_practices/query_tuning/query_hint.md References • sql-reference/System_variable.md • using_starrocks/running_queries.md • best_practices/query_tuning/query_hint.md • administration/management/monitor_manage_big_queries.md • administration/management/resource_management/Query_management.md Thinking Process: 1. Analyze the User's Request: The user wants to know how to specify a custom query ID when running a query in StarRocks. 2. Verify Information (from previous tool calls): * Tool call 
search_starrocks_doc
results confirm that a session variable 
custom_query_id
was introduced in v3.4.0. * It can be set via 
SET SESSION custom_query_id = 'id';
. _ It can also be set via a query hint: 
/_+ SET_VAR(custom_query_id = 'id') */
. * It's visible in 
SHOW PROC '/current_queries'
, audit logs (
customQueryId
field), and can be used with 
KILL QUERY 'id'
. 3. Synthesize the Answer: * State the feature name: 
custom_query_id
. * Specify the version requirement: v3.4.0+. * Provide the two main methods: 
SET SESSION
and 
SET_VAR
(query hint). * Briefly explain the benefits/usage (monitoring, killing queries, audit logs). 4. Format the Response: Use concise, clear Korean as requested by the user's language. Keep it brief. 5. Final Polish (Self-Correction): Ensure no competitor brands are mentioned. Ensure the tone is helpful and direct. (The previous model response was good, I will provide a similar concise version).StarRocks v3.4.0 버전부터 
custom_query_id
 시스템 변수를 사용하여 쿼리에 사용자 정의 ID를 부여할 수 있습니다. 이를 통해 외부 시스템의 작업 ID를 StarRocks 쿼리와 매핑하여 모니터링하거나 제어하기가 매우 쉬워집니다. 다음은 두 가지 주요 사용 방법입니다. 1. 쿼리 힌트를 사용한 지정 (권장) 쿼리 문장에 직접 힌트를 포함하는 방식입니다. 이 방식은 해당 단일 쿼리에만 적용되므로 가장 깔끔합니다.
Copy code
sql
SELECT /*+ SET_VAR(custom_query_id = 'my_job_id_001') */ 
    * 
FROM your_table 
WHERE ...;
2. 세션 변수 설정을 통한 지정 쿼리 실행 전에 현재 세션에서 ID를 설정하는 방식입니다. 설정 후 실행되는 쿼리에 해당 ID가 부여되며, 쿼리가 끝나면 값은 초기화됩니다.
Copy code
sql
-- 1. 커스텀 ID 설정
SET SESSION custom_query_id = 'my_job_id_001';

-- 2. 쿼리 실행
SELECT * FROM your_table WHERE ...;
────────── 주요 활용 기능 지정한 `custom_query_id`는 다음과 같은 상황에서 유용하게 사용됩니다.
* 쿼리 확인: 
SHOW PROC '/current_queries'
명령어를 실행하면 
CustomQueryId
컬럼에서 사용자가 지정한 ID를 확인할 수 있습니다. * 쿼리 강제 종료: 시스템이 생성한 긴 UUID 대신, 지정한 커스텀 ID로 쿼리를 종료할 수 있습니다. * 
KILL QUERY 'my_job_id_001';
* 로그 분석: FE의 감사 로그(
fe.audit.log
) 내 
customQueryId
필드에 해당 값이 기록되어 나중에 특정 작업의 쿼리를 추적하기 쉽습니다. 참고: 이 기능은 *v3.4.0 이상*에서만 지원되므로, 하위 버전을 사용 중이라면 업그레이드가 필요합니다. 레이드가 필요합니다. References • sql-reference/System_variable.md • using_starrocks/running_queries.md • best_practices/query_tuning/query_hint.md /query_hint) References • best_practices/query_tuning/query_hint.md • sql-reference/System_variable.md
r
@Rocky hdfs_backend_selector_force_rebalance 를 iceberg + 대규모 클러스터에서 사용하면 어떻게되는가 (query queue, data cachE 도 사용)
r
`hdfs_backend_selector_force_rebalance`는 StarRocks에서 HDFS나 S3와 같은 외부 저장소(External Table/Catalog)의 데이터를 스캔할 때, *데이터 스캔 범위(Scan Range)를 백엔드(BE) 노드들에 할당하는 알고리즘을 강제로 재분산(Rebalance)*하도록 설정하는 세션 변수입니다. 이 설정을 Iceberg + 대규모 클러스터 + 데이터 캐시 + 쿼리 큐 환경에서 사용할 때의 영향과 동작 방식은 다음과 같습니다. 1. 동작 원리: 부하 분산 vs 데이터 로컬리티(캐시) 기본적으로 StarRocks는 외부 테이블 쿼리 시 일관된 해싱(Consistent Hashing) 등을 사용하여 특정 파일(Split)을 항상 동일한 BE 노드에 할당하려고 노력합니다. 이는 *Data Cache(데이터 캐시)*의 히트율을 높이기 위함입니다. 동일한 데이터가 항상 같은 BE로 가야 그 노드의 로컬 디스크 캐시를 재사용할 수 있기 때문입니다. `hdfs_backend_selector_force_rebalance = true`로 설정하면: * 부하 분산 우선: 데이터 로컬리티(캐시 위치)보다 *노드 간 작업량 균형*을 우선시합니다. * 동작: 특정 BE에 작업이 몰리는 것을 방지하기 위해 스캔 범위를 최대한 모든 BE에 균등하게 분배합니다. 2. 대규모 클러스터에서의 영향 (장점) * 스큐(Skew) 해결: 대규모 클러스터에서는 데이터 분포나 노드 성능 차이로 인해 특정 BE 노드가 병목(Long-tail)이 되는 현상이 자주 발생합니다. 이 옵션은 작업을 강제로 균등 배분하여 특정 노드 때문에 전체 쿼리가 느려지는 현상을 효과적으로 줄여줍니다. * 전체 처리량 향상: 모든 BE의 CPU와 네트워크 자원을 최대한 골고루 활용하게 되어, 대량의 데이터를 처리하는 배치성 쿼리에서 성능 이득을 볼 수 있습니다. 3. 데이터 캐시(Data Cache)와의 충돌 (단점) * 캐시 히트율(Cache Hit Rate) 하락: 이 옵션의 가장 큰 부작용입니다. 어제 쿼리할 때는 BE-1이 처리했던 데이터가 오늘 재분산에 의해 BE-2로 할당될 수 있습니다. 이 경우 BE-2는 해당 데이터의 캐시가 없으므로 다시 원격 저장소(HDFS/S3)에서 데이터를 읽어와야 합니다. * 캐시 오염 및 IO 증가: 캐시 미스가 발생하면 원격 IO가 발생하고, 각 노드는 새로운 데이터를 캐싱하기 위해 기존 캐시를 밀어내는(Eviction) 작업이 빈번해져 시스템 전체의 IO 부하가 늘어날 수 있습니다. 4. 쿼리 큐(Query Queue)와의 상호작용 * 큐 대기 시간 감소 가능성: 특정 쿼리가 노드 스큐로 인해 한두 개 노드에서 오래 머물면, 해당 쿼리가 완료될 때까지 큐의 슬롯을 차지하게 됩니다. 작업을 균등하게 배분해 쿼리를 빨리 끝내면 큐 회전율이 좋아집니다. * 시스템 부하 가중 우려: 캐시 히트율이 낮아지면 개별 쿼리의 실행 시간(Latency) 자체가 늘어날 수 있습니다. 만약 원격 저장소(HDFS)의 IO 성능이 충분치 않다면, 쿼리들이 길어지면서 오히려 큐에 더 많은 쿼리가 쌓이는 역효과가 날 수도 있습니다. 요약 및 권장 사항 환경/지표 | 
force_rebalance = true
시 예상 결과 작업 부하 | 노드별 CPU/네트워크 부하가 **매우 균등**해짐 데이터 캐시 | 히트율이 **크게 하락**할 가능성이 높음 대규모 클러스터 | 특정 노드 병목(Long-tail) 현상이 제거되어 안정성 향상 쿼리 큐 | 쿼리 완결성이 좋아져 **큐 회전율 향상**에 도움 (단, 캐시 의존도 낮을 때) 추천 전략: 1. 배치성 작업: 캐시 히트보다 전체 노드 자원을 다 써서 빨리 끝내는 게 중요한 *대형 Import나 배치 쿼리*에서는 이 옵션을 `true`로 설정하는 것이 유리합니다. 2. 조회성 작업: 반복적인 조회가 많고 *데이터 캐시 성능이 중요*한 서비스 쿼리에서는 기본값(
false
)을 유지하여 캐시 히트율을 보호하는 것이 좋습니다. 3. 결론: 대규모 클러스터에서 유독 몇몇 노드만 CPU가 높고 쿼리 프로파일에서 특정 노드의 스캔 시간이 유독 길게 나타난다면, 이 옵션 사용을 적극 검토하십시오. References • data_source/data_cache.md • data_source/catalog/iceberg/iceberg_catalog.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md • best_practices/query_tuning/query_profile_operator_metrics.md References • data_source/data_cache_observe.md • data_source/data_cache.md
r
@Rocky querye_mem_limit을 10gb로 설정하면 만약 노드가 100 대라면 하나의 쿼리당 10기가 * 100대 만큼의 메모리를 쓸 수 있는건가?
r
네, 정확합니다. StarRocks에서 *`query_mem_limit`은 클러스터 전체 합계가 아니라 "BE 노드당(Per-node)" 제한*입니다. 따라서 말씀하신 것처럼 `query_mem_limit`을 10GB로 설정하고 노드가 100대라면, 이론적으로 하나의 쿼리가 클러스터 전체에서 최대 *10GB × 100대 = 1TB*의 메모리를 사용할 수 있습니다. 이와 관련하여 꼭 알아두어야 할 핵심 동작 방식은 다음과 같습니다. 1. 노드 단위의 엄격한 제한: 쿼리가 실행되는 동안 단 한 대의 노드라도 설정된 10GB를 초과하면 해당 쿼리는 즉시 종료(Fail)됩니다. 다른 99대의 노드에서 메모리를 아주 적게 쓰고 있더라도 상관없습니다. 2. 데이터 분포의 중요성: 만약 특정 노드에 데이터나 연산이 쏠려 있다면(Data Skew), 해당 노드만 10GB에 도달하여 쿼리가 실패할 수 있습니다. 이 경우 클러스터 전체 메모리 자원은 넉넉해도 쿼리가 완주하지 못합니다. 3. 리소스 그룹과의 관계: 리소스 그룹에서 설정하는 
big_query_mem_limit
역시 동일하게 노드당 제한값으로 작동합니다. 4. 기본값 0의 의미: 만약 `query_mem_limit`이 0으로 설정되어 있다면, 개별 쿼리에 대한 명시적 제한은 없으며 BE 노드 전체의 가용 메모리(
mem_limit
) 범위 내에서 최대한 사용하게 됩니다. 결론적으로, 대규모 클러스터일수록 개별 노드의 부하 분산이 잘 되어 있다면 `query_mem_limit`에 노드 개수를 곱한 만큼의 막대한 총 메모리 자원을 활용할 수 있습니다. References • sql-reference/System_variable.md • faq/resource_isolation_faq.md • administration/management/resource_management/Memory_management.md References • sql-reference/System_variable.md • faq/resource_isolation_faq.md • administration/management/resource_management/Memory_management.md • administration/management/resource_management/resource_group.md • administration/management/monitor_manage_big_queries.md queries) References • faq/resource_isolation_faq.md • sql-reference/System_variable.md • administration/management/resource_management/resource_group.md • administration/management/resource_management/Memory_management.md
r
@Rocky 쿼리별로 대이터 캐시 얼마나 사용됐는지 볼 수 있어?
r
네, *Query Profile(쿼리 프로필)*을 분석하면 개별 쿼리별로 데이터 캐시(Data Cache/Block Cache)를 얼마나 사용했는지 상세하게 확인할 수 있습니다. 쿼리 실행 후 
get_query_profile()
함수나 관리 콘솔의 프로필 상세 화면에서 다음 지표들을 확인해 보세요. 프로필에서 확인해야 할 핵심 지표 스캔 노드(예: 
HdfsScanNode
또는 
IcebergScanNode
)의 상세 항목을 보면 다음과 같은 지표가 나타납니다. 1. 
DataCacheReadBytes
: *캐시 히트*된 데이터의 양입니다. 시스템이 로컬 메모리나 디스크 캐시에서 직접 읽어온 데이터 크기를 나타냅니다. 2. 
DataCacheWriteBytes
: *캐시 미스*가 발생하여 원격 저장소(S3, HDFS 등)에서 읽어와 캐시에 새로 쓴 데이터의 양입니다. 3. 
BytesRead
: 쿼리에서 읽은 *전체 데이터 양*입니다. (일반적으로 
DataCacheReadBytes
+ 원격지에서 직접 읽은 양) 4. 
DataCacheReadTimer
/ 
DataCacheWriteTimer
: 캐시에서 데이터를 읽거나 쓰는 데 걸린 시간입니다. ────────── 예시 상황별 분석 방법 * 캐시 히트율이 높은 경우: * `DataCacheReadBytes`가 전체 `BytesRead`와 거의 일치합니다. * `DataCacheWriteBytes`가 0이거나 매우 작습니다. _ _해석: 이미 캐싱된 데이터를 사용하여 쿼리가 매우 빠르게 수행됨.* * 캐시 히트율이 낮은 경우 (처음 실행하는 쿼리 등): * 
DataCacheReadBytes
수치가 작습니다. * 
DataCacheWriteBytes
수치가 큽니다. (원격 저장소에서 데이터를 가져와 캐시에 채우는 과정) _ _해석: 데이터 캐시를 채우는 중이거나, 캐시 공간이 부족해 기존 캐시가 밀려났을 가능성이 있음.* 확인 방법 (SQL) 최근 실행한 쿼리의 프로필 ID를 확인한 뒤 아래 명령어로 상세 내용을 볼 수 있습니다.
Copy code
sql
-- 1. 최근 실행된 쿼리의 ID 확인
SELECT last_query_id();

-- 2. 해당 쿼리의 프로필 확인 (출력 내용 중 DataCacheReadBytes 검색)
SELECT get_query_profile('사용자_쿼리_ID');
만약 특정 쿼리가 캐시를 타지 않는 것 같다면, 앞서 질문하신 
hdfs_backend_selector_force_rebalance
설정이 `true`로 되어 있어 노드 간 작업이 재분산되면서 캐시 로컬리티가 깨진 것인지 함께 체크해 보시는 것이 좋습니다. References • data_source/data_cache.md • data_source/data_cache_observe.md • using_starrocks/caching/block_cache.md References • data_source/data_cache.md • using_starrocks/caching/block_cache.md • using_starrocks/caching/query_cache.md • data_source/data_cache_observe.md
r
@Rocky Starrocks CN 에서 datacache size not following pvc size, which filesystem should i use for disk?
r
StarRocks CN(Compute Node)에서 데이터 캐시(Block Cache) 크기가 PVC 크기를 자동으로 따라가지 않는 이유는 StarRocks 내부 설정에서 *기본적으로 전체 디스크 용량의 80%만 사용하도록 제한*되어 있거나, 명시적인 용량이 설정되어 있기 때문입니다. 1. 캐시 크기가 PVC를 따르지 않는 이유와 해결 방법 StarRocks의 데이터 캐시 용량은 
cn.conf
(또는 BE 설정)의 다음 두 파라미터 중 *더 큰 값*을 기준으로 결정됩니다. * 
starlet_star_cache_disk_size_percent
: 디스크 전체 용량 중 사용할 비율 (기본값: 80) * 
datacache_disk_size
: 사용할 고정 용량 (예: 
500G
, 
1T
. 기본값: 
0
) 해결 방법: PVC 용량을 최대한 활용하고 싶다면, `cn.conf`에서 비율을 높이거나 고정 용량을 PVC 크기에 맞춰 명시해야 합니다.
Copy code
properties
# 예: 디스크의 90%를 캐시로 사용하도록 설정
starlet_star_cache_disk_size_percent = 90

# 또는 PVC 용량이 500GB라면 직접 지정
datacache_disk_size = 450G
주의: 로그 파일, 코어 덤프, 메타데이터 공간을 위해 최소 10% 정도의 여유 공간을 남겨두는 것이 좋습니다. ────────── 2. 권장되는 파일 시스템 (Filesystem) StarRocks는 고성능 OLAP 처리를 위해 다음과 같은 가이드를 제공합니다. * 권장 파일 시스템: XFS * StarRocks는 대용량 파일 처리와 동시 I/O 성능이 뛰어난 *XFS*에서 가장 좋은 성능(QPS 등)을 보입니다. * 공식 문서에서도 EXT4보다 XFS를 우선적으로 권장합니다. * 차선책: EXT4 * 사용 가능하지만 XFS에 비해 대규모 동시성 작업 시 성능이 다소 떨어질 수 있습니다. * 피해야 할 것: EXT3 * 파일 시스템 이슈가 발생할 수 있으므로 권장하지 않습니다. ────────── 3. 추가 팁 (왜 사용량이 변하지 않는가?) 캐시 크기를 설정한 후에도 `du`나 `ls`로 확인하면 실제 데이터양보다 디스크 사용량이 높게 나타날 수 있습니다. * Peak Usage 유지: 데이터 캐시는 한 번 사용한 공간을 바로 반환하지 않고 "재사용 가능" 상태로 마킹만 합니다. 따라서 디스크 사용량은 *과거 최대치(Peak)*에 머물러 있는 것이 정상적인 동작입니다. * 교체 정책(LRU): 설정한 한도(80~90%)에 도달하면 가장 오래된 데이터부터 자동으로 밀어내고 새 데이터를 씁니다. 요약 1. 캐시 설정 변경: `starlet_star_cache_disk_size_percent`를 90 정도로 높이거나 `datacache_disk_size`를 직접 지정하세요. 2. 파일 시스템: 반드시 *XFS*를 사용하고, 물리적으로는 NVMe SSD 환경을 권장합니다. References • using_starrocks/caching/block_cache.md • faq/operation_maintenance_faq.md • administration/management/BE_configuration.md • data_source/data_cache.md • data_source/data_cache_troubleshooting.md troubleshooting) References • faq/operation_maintenance_faq.md • data_source/data_cache_troubleshooting.md • data_source/data_cache.md • using_starrocks/caching/block_cache.md • deployment/shared_data/feature-support-shared-data.md
r
@Rocky Starrocks 4.0.4 에서 Starrocks 4.1.1 버전으로 업그레이드 했는데 아래의 문제가 발생 1. 4.0.4 에서 추가한 Oracle Catalog의 Table 중 컬럼에 Number가 있으면 조회가 안됨 4.1.1 에서는 개선이 됐다고 하는데 안되는 이유는? 2. 4.1.1 신규 클러스터에 Oracal catalog를 추가하고 조회하면 정상적으로 조회됨.
r
StarRocks 4.0.4에서 4.1.1로 업그레이드 후 기존 Oracle Catalog의 
NUMBER
컬럼 조회가 되지 않는 문제는, *기존에 생성된 카탈로그가 4.0.4 버전의 메타데이터 캐시(Schema) 정보를 그대로 들고 있기 때문*일 가능성이 매우 높습니다. 4.1.1 버전에서는 Oracle JDBC의 데이터 타입 호환성(특히 
NUMBER
타입 매핑 및 정밀도 처리)에 대한 개선 및 변경 사항이 포함되었으나, 업그레이드된 클러스터의 FE(Frontend) 메모리에는 여전히 4.0.4 시절의 잘못된 혹은 구버전 방식의 스키마 정보가 캐싱되어 있어 신규 버전의 쿼리 엔진과 충돌이 발생하는 것입니다. 이 문제를 해결하기 위해 다음 방법들을 시도해 보시기 바랍니다. 1. 메타데이터 강제 새로고침 (가장 권장하는 방법) 해당 테이블 또는 데이터베이스의 메타데이터 캐시를 최신 상태로 갱신하여 4.1.1의 새로운 타입 매핑 로직이 적용되도록 합니다.
Copy code
sql
-- 특정 테이블의 메타데이터를 새로 고칩니다.
REFRESH EXTERNAL TABLE <oracle_catalog_name>.<db_name>.<table_name>;

-- 또는 해당 데이터베이스 전체를 새로 고칩니다.
-- (StarRocks는 카탈로그 전체 리프레시보다는 테이블 단위 리프레시를 권장합니다.)
2. 카탈로그 속성 확인 및 재설정 4.1 버전부터 Oracle 
NUMBER
타입 처리를 위해 추가되거나 개선된 속성이 있을 수 있습니다. 만약 1번으로 해결되지 않는다면, 카탈로그 생성 시 사용했던 속성에 아래 옵션을 명시적으로 추가하여 다시 생성(DROP 후 CREATE)해 보시기 바랍니다. * 
oracle.number.default-scale
: Oracle 
NUMBER
타입에 명시적인 정밀도(precision)나 스케일(scale)이 없을 때 기본값으로 사용할 값을 지정합니다. (기본값: 6) 3. 왜 신규 클러스터는 잘 되나요? 신규 클러스터는 처음부터 4.1.1의 로직으로 Oracle의 메타데이터를 조회하고 StarRocks 내부 데이터 타입(일반적으로 
DECIMAL
)으로 매핑하여 캐싱하기 때문에 문제가 발생하지 않습니다. 반면 업그레이드된 클러스터는 과거 버전에서 매핑된 "오래된 스키마 정보"를 유지하고 있어, 쿼리 실행 단계에서 실제 데이터와 메타데이터 간의 불일치가 발생하게 됩니다. 결론적으로, 
REFRESH EXTERNAL TABLE
명령어를 통해 해당 테이블들의 메타데이터를 4.1.1 기준으로 다시 불러오시면 해결될 것입니다. References • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/table_bucket_part_index/REFRESH_EXTERNAL_TABLE.md • release_notes/release-4.1.md (Release notes highlighting JDBC compatibility improvements) References • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/table_bucket_part_index/REFRESH_EXTERNAL_TABLE.md • data_source/feature-support-data-lake-analytics.md • data_source/External_table.md • release_notes/release-3.2.md -3.2) References • data_source/catalog/maxcompute_catalog.md • data_source/catalog/hive_catalog.md • data_source/catalog/hudi_catalog.md • sql-reference/sql-statements/table_bucket_part_index/REFRESH_EXTERNAL_TABLE.md
r
@Rocky Starrocks 4.0.4 에서 Starrocks 4.1.1 버전으로 업그레이드 했는데 아래의 문제가 발생 1. 4.0.4 에서 추가한 Oracle Catalog의 Table 중 컬럼에 Number가 있으면 조회가 안됨 4.1.1 에서는 개선이 됐다고 하는데 안되는 이유는? 2. 4.1.1 신규 클러스터에 Oracal catalog를 추가하고 조회하면 정상적으로 조회됨. 확인해보니 show tables in oracle_catalog.database; 이것도 안됨 DETAIL MESSAGE: UNKNOWN TABLE ''
r
StarRocks 4.0.4에서 4.1.1로 업그레이드한 후 발생하는 이 문제는 *FE(Frontend)에 저장된 기존 카탈로그의 메타데이터 캐시 구조가 4.1 버전의 새로운 데이터 레이아웃 및 JDBC 타입 매핑 로직과 호환되지 않아 발생하는 전형적인 메타데이터 오염 현상*입니다. 신규 클러스터에서 정상 작동하는 것은 4.1.1의 로직으로 메타데이터를 처음부터 깨끗하게 읽어왔기 때문입니다. 업그레이드된 환경에서는 
NUMBER
타입 처리 방식이 개선되었음에도 불구하고, FE 메모리나 BDB-JE(내부 저장소)에 남아있는 4.0 시절의 메타데이터가 충돌을 일으켜 테이블 이름조차 인식하지 못하는(
UNKNOWN TABLE ''
) 상태가 된 것입니다. 이 문제를 해결하기 위한 단계별 조치 방법은 다음과 같습니다. 1. 카탈로그 삭제 후 재생성 (가장 확실한 해결책) `SHOW TABLES`조차 되지 않는 상황은 데이터베이스 내의 테이블 목록 메타데이터 자체가 깨진 상태임을 의미합니다. 단순히 테이블 하나를 `REFRESH`하는 것으로는 부족하며, 카탈로그를 삭제하고 다시 생성하여 4.1.1 기준의 메타데이터를 다시 빌드해야 합니다.
Copy code
sql
-- 1. 기존 카탈로그 삭제
DROP CATALOG <oracle_catalog_name>;

-- 2. 카탈로그 재생성 (기존과 동일한 설정 사용)
CREATE EXTERNAL CATALOG <oracle_catalog_name>
PROPERTIES (
    "type" = "jdbc",
    "user" = "<username>",
    "password" = "<password>",
    "jdbc_url" = "jdbc:oracle:thin:@<host>:<port>:<sid>",
    "driver_url" = "<driver_path>",
    "driver_class" = "oracle.jdbc.driver.OracleDriver"
);
2. Oracle NUMBER 타입 관련 속성 확인 4.1 버전부터는 Oracle의 
NUMBER
타입을 더 정확하게 처리하기 위해 정밀도(Precision)와 스케일(Scale)을 다루는 방식이 세분화되었습니다. 카탈로그 생성 시 아래 속성을 명시적으로 추가해 보시기 바랍니다. * 
oracle.number.default-scale
: Oracle에서 
NUMBER
타입에 명시적인 소수점 자릿수가 없을 때 기본값으로 사용할 크기입니다. (기본값: 10) * 만약 여전히 조회가 안 된다면, 4.1.1에서 도입된 
DECIMAL256
 관련 호환성을 확인해야 합니다. 매우 큰 
NUMBER
타입은 이제 StarRocks의 `DECIMAL128`이나 `DECIMAL256`으로 매핑되는데, 이 과정에서 이전 버전의 스키마와 충돌할 수 있습니다. 3. FE 로그 확인 (원인 파악) 
UNKNOWN TABLE ''
에러는 FE가 메타데이터를 역직렬화(Deserialization)하는 과정에서 예외가 발생하여 테이블 이름을 빈 값으로 리턴할 때 주로 발생합니다. * FE의 
fe.warn.log
파일을 확인하여 
SHOW TABLES
명령 시 발생하는 *Stack Trace*를 살펴보세요. * `NullPointerException`이나 `IllegalArgumentException`과 함께 타입 매핑 오류가 찍혀 있다면 메타데이터 불일치가 확실합니다. 요약 1. 현상: 업그레이드 시 이전 버전의 Oracle 메타데이터 구조가 FE에 남아 4.1.1의 개선된 JDBC 엔진과 충돌. 2. 조치: 
REFRESH
명령어가 먹히지 않는 수준이므로 *`DROP CATALOG` 후 다시 `CREATE CATALOG`*를 수행하여 메타데이터를 완전히 새로 고침하십시오. 3. 주의: 4.1 버전은 이전 버전으로의 다운그레이드가 제한될 정도로 메타데이터 구조 변화가 크므로, 반드시 카탈로그 재생성을 통해 4.1 전용 메타데이터를 생성해야 합니다. References • release_notes/release-4.1.md (Release notes highlighting metadata layout changes and JDBC improvements) • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/table_bucket_part_index/REFRESH_EXTERNAL_TABLE.md • administration/management/FE_configuration.md
2 Views
Open in Slack
PreviousNext
Powered by