http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> 특정 시점의 동시 쿼리 실행 수 테이블 scan 사이즈 등을 알...
# questions-and-troubleshooting
s
@Rocky 특정 시점의 동시 쿼리 실행 수 테이블 scan 사이즈 등을 알수있을까?
r
특정 시점의 동시 쿼리 실행 수와 테이블 스캔 사이즈(ScanBytes)를 확인하는 방법은 *현재 상태 확인*과 과거 이력(History) 확인 두 가지 관점에서 가능합니다. 1. 실시간/현재 상태 확인 (Real-time) 현재 시점에서 실행 중인 쿼리 수와 각 쿼리의 스캔 사이즈를 확인하고 싶다면 아래 명령어를 사용합니다. * 현재 실행 중인 모든 쿼리의 상세 정보:
Copy code
sql
    SHOW PROC '/current_queries';
* 
QueryId
, 
ScanBytes
(스캔한 데이터 크기), 
ScanRows
, 
MemoryUsage
, 
ExecTime
등의 정보를 한눈에 볼 수 있습니다. * 백엔드별 실행 중인 쿼리 수:
Copy code
sql
    SHOW PROC '/backends';
* 
NumRunningQueries
컬럼을 통해 각 BE 노드에서 현재 실행 중인 쿼리 개수를 확인할 수 있습니다. * FE 콘솔 이용: 브라우저에서 `http//&lt;fe ip&gt;<fe_http_port>/system?path=//current_queries`에 접속하면 시각화된 대시보드 형태로 현재 쿼리들을 모니터링할 수 있습니다. 2. 특정 시점의 과거 이력 확인 (Historical) 특정 시점에 얼마나 많은 쿼리가 실행되었는지, 스캔 사이즈가 어떠했는지 확인하려면 Audit Log(감사 로그) 분석이 필요합니다. * FE Audit Log (
fe.audit.log
): StarRocks는 모든 쿼리 실행 이력을 
fe/log/fe.audit.log
파일에 저장합니다. 이 로그에는 다음 필드들이 포함됩니다: * `timestamp`: 쿼리 시작 시간 * `queryTime`: 쿼리 실행 소요 시간 (ms) * `scanBytes`: 해당 쿼리가 스캔한 총 바이트 수 * `scanRows`: 스캔한 행 수 * 동시 쿼리 계산 방법: 특정 시점 $T$에 실행 중이었던 쿼리는 
timestamp <= T
이면서 `timestamp + queryTime >= T`인 로그 항목들을 카운트하여 산출할 수 있습니다. * AuditLoader 플러그인 (권장): 로그 파일을 직접 분석하는 대신 
AuditLoader
플러그인을 설치하면 감사 로그를 StarRocks 내부 테이블에 자동으로 저장할 수 있습니다.
Copy code
sql
    -- AuditLoader가 설치된 경우 예시 쿼리
    SELECT
        queryId,
        timestamp,
        queryTime,
        scanBytes
    FROM starrocks_audit_db*.starrocks_audit_tbl*
    WHERE timestamp BETWEEN '2023-10-27 10:00:00' AND '2023-10-27 10:01:00';
3. 모니터링 시스템 연동 (Prometheus/Grafana) Grafana 대시보드를 구축해 두었다면 차트를 통해 특정 시점의 지표를 직관적으로 볼 수 있습니다. * 동시 쿼리 수: 
starrocks_fe_query_resource_group_running_queries
또는 
starrocks_fe_query_total
(Rate 사용) 지표를 확인합니다. * 스캔 사이즈: 
starrocks_be_query_scan_bytes_total
지표를 통해 클러스터 전체의 스캔 처리량을 확인할 수 있습니다. 요약하자면: * 지금 바로 알고 싶다면: 
SHOW PROC '/current_queries';
* *어제 특정 시간*의 기록을 알고 싶다면: Audit Log 확인 또는 AuditLoader 테이블 조회를 사용하시면 됩니다. References • administration/management/audit_loader.md
s
@Rocky Fininshed Queries 를 볼수있을까?? 어디 저장된게있어?
r
실행이 완료된 쿼리(Finished Queries)의 이력과 상세 정보는 크게 두 가지 경로를 통해 확인할 수 있습니다. 1. 감사 로그 (Audit Log) - 장기 이력 확인 모든 쿼리의 실행 기록(쿼리문, 실행 시간, 스캔 사이즈 등)은 기본적으로 파일 형태로 저장됩니다. * 저장 위치: FE(Frontend) 서버의 
fe/log/fe.audit.log
파일 * 확인 방법: * 서버에서 직접 
grep
등으로 로그를 조회하거나, * AuditLoader 플러그인을 설치하여 로그를 StarRocks 내부 테이블로 로드하면 SQL로 조회가 가능합니다. * SQL 예시 (AuditLoader 사용 시):
Copy code
sql
        SELECT queryId, timestamp, queryTime, scanBytes, stmt
        FROM starrocks_audit_db*.starrocks_audit_tbl*
        ORDER BY timestamp DESC;
2. 프로파일 리스트 (Profile List) - 최근 쿼리 상세 분석 쿼리의 실행 계획이나 단계별 성능 지표를 포함한 상세 정보를 확인하고 싶을 때 사용합니다. (StarRocks v3.1 이상 권장) * 확인 방법 (SQL):
Copy code
sql
    -- 최근 완료된 쿼리 목록 확인
    SHOW PROFILELIST LIMIT 10;

    -- 특정 쿼리의 상세 실행 지표 확인 (QueryId 필요)
    -- 먼저 해당 기능이 켜져 있어야 합니다: SET enable_profile = true;
    ANALYZE PROFILE FROM 'query_id';
* 확인 방법 (Web UI): * 브라우저에서 `http//&lt;FE IP&gt;<FE_HTTP_PORT>/query`에 접속하면 시각화된 쿼리 이력과 상세 프로파일(Execution Profile)을 볼 수 있습니다. 3. 주요 차이점 요약 구분 | Audit Log (AuditLoader) | Profile (SHOW PROFILELIST) 용도 | 장기적인 쿼리 통계 및 감사 | 최근 쿼리의 성능 병목 지점 분석 저장 기간 | 로그 정리 정책이나 DB 파티션 설정에 따라 장기 보관 가능 | 최근 일정 개수(기본 100개 내외)만 메모리에 캐싱 포함 정보 | 쿼리문, 유저, 실행시간, ScanBytes, ScanRows 등 | 각 오퍼레이터별 소요 시간, CPU/메모리 상세 사용량 등 추천: 특정 시점의 전체적인 쿼리 통계와 스캔 사이즈를 분석하는 것이 목적이라면 *AuditLoader*를 설정하여 테이블 형태로 관리하는 것이 가장 효과적입니다. References • administration/management/audit_loader.md • sql-reference/sql-statements/cluster-management/plan_profile/SHOW_PROFILELIST.md References • developers/trace-tools/query_trace_profile.md • sql-reference/sql-statements/cluster-management/plan_profile/SHOW_PROFILELIST.md • administration/management/FE_configuration.md • administration/http_interface/query_detail.md
s
@Rocky 동시에 쿼리 몇건을 받는게 이상적이야?? FE 3개 각 24core/64GI CN 10개 16core/300GI거든
r
제시해주신 클러스터 스펙(FE 3대, CN 10대 / 총 160 코어)을 기준으로 적정 동시 쿼리 수를 산정하는 가이드를 드립니다. 1. 쿼리 성격에 따른 예상 동시 처리량 StarRocks는 CPU 코어 수와 쿼리의 복잡도에 따라 처리 성능이 크게 달라집니다. * 단순 조회 및 고빈도 쿼리 (Point Lookup 등): * 이 경우 CPU보다는 네트워크나 FE의 처리 능력이 병목이 됩니다. 160 코어 규모라면 초당 수천 건(QPS) 이상의 처리도 충분히 가능합니다. * 복잡한 분석용 쿼리 (대량 Join, Aggregation 등): * 일반적으로 *전체 CPU 코어 수의 1/4 ~ 1/2 수준*의 동시 쿼리가 수행될 때 자원 경합 없이 최적의 성능을 냅니다. * 귀하의 클러스터(총 160 코어) 기준, 대략 40~80개 정도의 복잡한 쿼리가 동시에 돌 때가 가장 효율적일 가능성이 높습니다. 2. 핵심 설정값 가이드 적정 수치를 찾기 위해 아래 두 가지 설정을 조정하며 테스트해보시는 것을 권장합니다. * 
pipeline_dop
(Degree of Parallelism): * 하나의 쿼리가 한 대의 CN에서 사용하는 병렬 스레드 수입니다. 보통 *코어 수의 절반*으로 설정합니다. * 귀하의 경우 CN이 16코어이므로 `pipeline_dop = 8`이 기본 권장값입니다. * 만약 동시 접속자 수가 매우 많다면 이 값을 낮춰서(예: 4) 더 많은 쿼리가 자원을 나눠 쓰게 할 수 있습니다. * 
query_queue_concurrency_limit
(쿼리 대기열): * 시스템 과부하를 막기 위해 동시 실행 쿼리 수를 제한하는 설정입니다. * 초기값으로 100~200 정도를 설정해 보시고, CPU 사용률이 80%를 넘지 않는 선에서 점진적으로 늘려가며 최적의 지점을 찾으십시오. 3. 리소스 그룹(Resource Group) 활용 (권장) 사용자나 업무 성격에 따라 자원을 격리하는 것이 좋습니다. * 예: 대시보드용(우선순위 높음, 낮은 지연시간), 배치 분석용(우선순위 낮음, 높은 처리량) * v3.1 이상이라면 *Resource Group*에 `concurrency_limit`를 설정하여 특정 업무가 전체 자원을 점유하지 못하도록 강제할 수 있습니다. 요약 및 추천 전략 1. 초기 권장 동시 실행 수: 약 100개 내외로 제한을 걸고 모니터링을 시작하세요. 2. 모니터링 지표: Grafana나 `SHOW PROC '/backends';`를 통해 *CPU 사용률(CPU Utilization)*을 확인하십시오. 3. 조정: * CPU가 놀고 있다면(
30-40%
미만) `query_queue_concurrency_limit`를 늘립니다. * CPU가 너무 높고(
90%
이상) 쿼리 응답 속도가 느려진다면 제한을 낮춥니다. 현재 스펙은 CN 10대에 메모리도 300GB로 넉넉한 편이므로, 설정만 잘 하신다면 대규모 트래픽도 충분히 안정적으로 수용 가능합니다. References • administration/management/resource_management/query_queues.md • administration/management/resource_management/Query_management.md • deployment/plan_cluster.md • faq/Others.md References • administration/management/resource_management/query_queues.md • administration/management/resource_management/Query_management.md
2 Views
Open in Slack
PreviousNext
Powered by