system.processors_profile_log

Table système contenant des informations de profilage au niveau des processeurs (disponibles dans EXPLAIN PIPELINE)

Interroger dans ClickHouse Cloud

Les données de cette table système sont stockées localement sur chaque nœud de ClickHouse Cloud. Pour obtenir une vue complète de l’ensemble des données, il faut donc utiliser la fonction clusterAllReplicas. Consultez cette page pour plus de détails.

​

Description

Cette table contient des données de profilage au niveau des processeurs (que vous pouvez retrouver dans EXPLAIN PIPELINE).

​

Colonnes

• hostname (LowCardinality(String)) — Nom d’hôte du serveur qui exécute la requête.
• event_date (Date) — Date à laquelle l’événement s’est produit.
• event_time (DateTime) — Date et heure auxquelles l’événement s’est produit.
• event_time_microseconds (DateTime64(6)) — Date et heure, avec une précision à la microseconde, auxquelles l’événement s’est produit.
• id (UInt64) — ID du processeur.
• parent_ids (Array(UInt64)) — ID des processeurs parents.
• plan_step (UInt64) — ID de l’étape du plan de requête qui a créé ce processeur. La valeur est égale à zéro si le processeur n’a été ajouté par aucune étape.
• plan_step_name (String) — Nom de l’étape du plan de requête qui a créé ce processeur. La valeur est vide si le processeur n’a été ajouté par aucune étape.
• plan_step_description (String) — Description de l’étape du plan de requête qui a créé ce processeur. La valeur est vide si le processeur n’a été ajouté par aucune étape.
• plan_group (UInt64) — Groupe du processeur s’il a été créé par une étape du plan de requête. Un groupe correspond à un partitionnement logique des processeurs ajoutés par la même étape du plan de requête. Il est utilisé uniquement pour rendre plus lisible le résultat de EXPLAIN PIPELINE.
• initial_query_id (String) — ID de la requête initiale (pour l’exécution distribuée des requêtes).
• query_id (String) — ID de la requête.
• name (LowCardinality(String)) — Nom du processeur.
• elapsed_us (UInt64) — Nombre de microsecondes pendant lesquelles ce processeur a été exécuté.
• input_wait_elapsed_us (UInt64) — Nombre de microsecondes pendant lesquelles ce processeur a attendu des données (provenant d’un autre processeur).
• output_wait_elapsed_us (UInt64) — Nombre de microsecondes pendant lesquelles ce processeur a attendu parce que le port de sortie était plein.
• input_rows (UInt64) — Nombre de lignes consommées par le processeur.
• input_bytes (UInt64) — Nombre d’octets consommés par le processeur.
• output_rows (UInt64) — Nombre de lignes générées par le processeur.
• output_bytes (UInt64) — Nombre d’octets générés par le processeur.
• processor_uniq_id (String) — ID unique du processeur dans le pipeline.
• step_uniq_id (String) — ID unique de l’étape dans le plan.

​

Exemple

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 │
└─────────────────────────┴────────────┴───────────────────────┴────────────────────────┘

Ici, vous pouvez voir :

• ExpressionTransform exécutait la fonction sleep(1), donc son work prendra 1e6, et elapsed_us > 1e6.
• SourceFromSingleChunk doit attendre, car ExpressionTransform n’accepte aucune donnée pendant l’exécution de sleep(1) ; il sera donc dans l’état PortFull pendant 1e6 us, et output_wait_elapsed_us > 1e6.
• LimitsCheckingTransform/NullSource/LazyOutputFormat doivent attendre que ExpressionTransform exécute sleep(1) pour traiter le résultat, donc input_wait_elapsed_us > 1e6.

​

Voir aussi

• EXPLAIN PIPELINE