system.processors_profile_log 시스템 테이블

system.processors_profile_log 는 프로세서 수준의 프로파일링 정보를 담고 있어요(EXPLAIN PIPELINE 에서 찾을 수 있는 것) 이 테이블은 언제든지 안전하게 truncate 하거나 drop 할 수 있어요.

출처: 문서

본문

ClickHouse Cloud에서의 조회 — 이 시스템 테이블의 데이터는 ClickHouse Cloud에서 각 노드에 로컬로 저장돼요. 따라서 모든 데이터의 완전한 뷰를 얻으려면 clusterAllReplicas 함수가 필요해요. 자세한 내용은 여기 를 참고하세요.

Description

이 테이블은 프로세서 수준의 프로파일링을 포함해요(EXPLAIN PIPELINE 에서 찾을 수 있는 것). 이 테이블은 언제든지 안전하게 truncate 하거나 drop 할 수 있어요.

Columns

hostname (LowCardinality(String)) — 쿼리를 실행한 서버의 호스트 이름이에요.
clickhouse_version (LowCardinality(String)) — 이 행을 만든 ClickHouse 서버의 버전이에요.
system_processor (LowCardinality(String)) — 이 행을 만든 ClickHouse 서버의 CPU 아키텍처예요.
event_date (Date) — 이벤트가 발생한 날짜예요.
event_time (DateTime) — 이벤트가 발생한 날짜와 시간이에요.
event_time_microseconds (DateTime64(6)) — 이벤트가 발생한 날짜와 시간(마이크로초 정밀도)이에요.
id (UInt64) — 프로세서 ID예요.
parent_ids (Array(UInt64)) — 상위 프로세서 ID예요.
plan_step (UInt64) — 이 프로세서를 만든 쿼리 플랜 단계의 ID예요. 프로세서가 어떤 단계에서도 추가되지 않았다면 값은 0이에요.
plan_step_name (String) — 이 프로세서를 만든 쿼리 플랜 단계의 이름이에요. 프로세서가 어떤 단계에서도 추가되지 않았다면 값은 비어 있어요.
plan_step_description (String) — 이 프로세서를 만든 쿼리 플랜 단계의 설명이에요. 프로세서가 어떤 단계에서도 추가되지 않았다면 값은 비어 있어요.
plan_group (UInt64) — 쿼리 플랜 단계가 만든 프로세서의 그룹이에요. 그룹은 같은 쿼리 플랜 단계에서 추가된 프로세서의 논리적 분할이에요. 그룹은 EXPLAIN PIPELINE 결과를 보기 좋게 하는 데만 사용돼요.
initial_query_id (String) — 동일한 쿼리 체인에서 초기 쿼리의 ID예요.
query_id (String) — 쿼리 ID예요.
name (LowCardinality(String)) — 프로세서의 이름이에요.
elapsed_us (UInt64) — 이 프로세서가 실행된 마이크로초 수예요.
input_wait_elapsed_us (UInt64) — 이 프로세서가 (다른 프로세서로부터) 데이터를 기다린 마이크로초 수예요.
output_wait_elapsed_us (UInt64) — 출력 포트가 가득 차서 이 프로세서가 기다린 마이크로초 수예요.
input_rows (UInt64) — 프로세서가 소비한 행 수예요.
input_bytes (UInt64) — 프로세서가 소비한 바이트 수예요.
output_rows (UInt64) — 프로세서가 생성한 행 수예요.
output_bytes (UInt64) — 프로세서가 생성한 바이트 수예요.
processor_uniq_id (String) — 파이프라인에서 고유한 프로세서 ID예요.
step_uniq_id (String) — 플랜에서 고유한 단계 ID예요.

Example

Query

EXPLAIN PIPELINE
SELECT sleep(1)
┌─explain─────────────────────────┐
│ (Expression)                    │
│ ExpressionTransform             │
│   (SettingQuotaAndLimits)       │
│     (ReadFromStorage)           │
│     SourceFromSingleChunk 0 → 1 │
└─────────────────────────────────┘

SELECT sleep(1)
SETTINGS log_processors_profiles = 1
Query id: feb5ed16-1c24-4227-aa54-78c02b3b27d4
┌─sleep(1)─┐
│        0 │
└──────────┘
1 rows in set. Elapsed: 1.018 sec.

SELECT
    name,
    elapsed_us,
    input_wait_elapsed_us,
    output_wait_elapsed_us
FROM system.processors_profile_log
WHERE query_id = 'feb5ed16-1c24-4227-aa54-78c02b3b27d4'
ORDER BY name ASC

Response

┌─name────────────────────┬─elapsed_us─┬─input_wait_elapsed_us─┬─output_wait_elapsed_us─┐
│ ExpressionTransform     │    1000497 │                  2823 │                    197 │
│ LazyOutputFormat        │         36 │               1002188 │                      0 │
│ LimitsCheckingTransform │         10 │               1002994 │                    106 │
│ NullSource              │          5 │               1002074 │                      0 │
│ NullSource              │          1 │               1002084 │                      0 │
│ SourceFromSingleChunk   │         45 │                  4736 │                1000819 │
└─────────────────────────┴────────────┴───────────────────────┴────────────────────────┘

여기서 다음을 볼 수 있어요:

ExpressionTransform 이 sleep(1) 함수를 실행했으므로 그 work 는 1e6 이 걸리고 elapsed_us > 1e6 이 돼요.
SourceFromSingleChunk 은 sleep(1) 실행 중 ExpressionTransform 이 데이터를 받지 않으므로 기다려야 해요. 그래서 1e6 us 동안 PortFull 상태가 되고 output_wait_elapsed_us > 1e6 이 돼요.
LimitsCheckingTransform/NullSource/LazyOutputFormat 은 ExpressionTransform 이 결과를 처리하기 위해 sleep(1) 을 실행할 때까지 기다려야 하므로 input_wait_elapsed_us > 1e6 이 돼요.

system.processors_profile_log 시스템 테이블

system.processors_profile_log 시스템 테이블

본문

Description

Columns

Example

See Also