본문으로 바로가기
본문으로 바로가기

system.processors_profile_log

ClickHouse Cloud에서 쿼리하기

이 시스템 테이블의 데이터는 ClickHouse Cloud의 각 노드에 로컬로 저장됩니다. 따라서 전체 데이터를 조회하려면 clusterAllReplicas 함수를 사용해야 합니다. 자세한 내용은 여기를 참고하십시오.

설명​

이 테이블에는 프로세서 수준의 프로파일링 데이터가 포함됩니다( EXPLAIN PIPELINE에서 확인할 수 있음).

컬럼​

  • hostname (LowCardinality(String)) — 쿼리를 실행하는 서버의 호스트명입니다.
  • 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입니다.

예시​

쿼리:

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

결과:

┌─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는 대기해야 합니다. ExpressionTransform이 sleep(1)을 실행하는 동안에는 어떤 데이터도 받지 않으므로 1e6 us 동안 PortFull 상태가 되며, 따라서 output_wait_elapsed_us > 1e6이 됩니다.
  • LimitsCheckingTransform/NullSource/LazyOutputFormat는 결과를 처리하기 위해 ExpressionTransform이 sleep(1) 실행을 완료할 때까지 대기해야 하므로 input_wait_elapsed_us > 1e6이 됩니다.

참고​