system.processors_profile_log

プロセッサレベルのプロファイリング情報を含むシステムテーブル （EXPLAIN PIPELINE で確認できます）

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。

​

例

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 は待機する必要があります。これは、ExpressionTransform が sleep(1) の実行中はデータを受け付けないためです。そのため、1e6 us の間 PortFull 状態となり、output_wait_elapsed_us > 1e6 になります。
• LimitsCheckingTransform/NullSource/LazyOutputFormat は、結果を処理するために ExpressionTransform が sleep(1) を実行し終えるまで待機する必要があるため、input_wait_elapsed_us > 1e6 になります。

​

関連項目

• EXPLAIN PIPELINE