IPC:parallel wait events - Amazon Aurora
Versions de moteur prises en chargeContexteCauses probables de l’augmentation du nombre d’événements d’attenteActions

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

IPC:parallel wait events

Les événements IPC:parallel wait events suivants indiquent qu’une session est en attente d’une communication interprocessus liée aux opérations d’exécution de requêtes parallèles.

  • IPC:BgWorkerStartup : un processus attend qu’un processus de travail parallèle termine sa séquence de démarrage. Cela se produit lors de l’initialisation des applications de travail pour l’exécution de requêtes parallèles.

  • IPC:BgWorkerShutdown : un processus attend la fin de la séquence d’arrêt d’un processus de travail parallèle. Cela se produit pendant la phase de nettoyage de l’exécution de requêtes parallèles.

  • IPC:ExecuteGather : un processus attend de recevoir des données de processus de travail en parallèle pendant l’exécution de la requête. Cela se produit lorsque le processus principal doit recueillir des résultats auprès de ses applications de travail.

  • IPC:ParallelFinish : un processus attend que les applications de travail en parallèle terminent leur exécution et publient leurs résultats finaux. Cela se produit pendant la phase de finalisation de l’exécution des requêtes parallèles.

Versions de moteur prises en charge

Ces informations sur les événements d’attente s’appliquent à toutes les versions d’Aurora PostgreSQL.

Contexte

L’exécution de requêtes parallèles dans PostgreSQL implique la collaboration de plusieurs processus pour le traitement d’une seule requête. Lorsqu’une requête est jugée appropriée pour la parallélisation, un processus principal est coordonné avec un ou plusieurs processus de travail en parallèle en fonction du réglage du paramètre max_parallel_workers_per_gather. Le processus principal répartit le travail entre les applications de travail, chaque application de travail traite sa partie des données de manière indépendante et les résultats sont renvoyés au processus principal.

Note

Chaque application de travail en parallèle fonctionne comme un processus distinct dont les besoins en ressources sont similaires à ceux d’une session utilisateur complète. Une requête parallèle avec quatre applications de travail peut ainsi consommer jusqu’à cinq fois plus de ressources (processeur, mémoire, bande passante d’E/S) par rapport à une requête non exécutée en parallèle, car le processus principal et chaque processus de travail conservent leurs propres allocations de ressources. Par exemple, des paramètres tels que work_mem sont appliqués individuellement à chaque application de travail, multipliant potentiellement l’utilisation totale de la mémoire entre tous les processus.

L’architecture des requêtes parallèles comprend trois composants principaux :

  • Processus principal : processus clé qui initie l’opération en parallèle, répartit la charge de travail et assure la coordination avec les processus de travail.

  • Processus de travail : processus d’arrière-plan qui exécutent des parties de la requête parallèle.

  • Fusion Gather/Gather : opérations qui combinent les résultats de plusieurs processus de travail pour les renvoyer au processus principal.

Lors d’une exécution en parallèle, les processus doivent communiquer entre eux par le biais de mécanismes de communication interprocessus (IPC). Ces événements d’attente IPC se produisent au cours de différentes phases :

  • Démarrage des applications de travail : lorsque des applications de travail en parallèle sont initialisées

  • Échange de données : lorsque les applications de travail traitent les données et envoient les résultats au processus principal

  • Arrêt des applications de travail : lorsque l’exécution en parallèle est terminée et que les applications de travail sont arrêtées

  • Points de synchronisation : lorsque les processus doivent se coordonner ou attendre que d’autres processus terminent leurs tâches

Il est essentiel de comprendre ces événements d’attente pour pouvoir résoudre les problèmes de performances liés à l’exécution de requêtes parallèles, en particulier dans les environnements à forte concurrence dans lesquels plusieurs requêtes parallèles peuvent s’exécuter simultanément.

Causes probables de l’augmentation du nombre d’événements d’attente

Plusieurs facteurs peuvent contribuer à augmenter le nombre d’événements d’attente IPC liés à l’exécution de requêtes parallèles :

Forte concurrence des requêtes parallèles

Lorsque de nombreuses requêtes parallèles sont exécutées simultanément, cela peut entraîner une contention des ressources et une augmentation des temps d’attente pour les opérations IPC. Cela est particulièrement courant dans les systèmes impliquant des volumes de transactions ou des charges de travail analytiques élevés.

Plans de requêtes parallèles sous-optimaux

Si le planificateur de requêtes choisit des plans de requêtes parallèles inefficaces, cela peut entraîner une parallélisation inutile ou une mauvaise répartition du travail entre les applications de travail. Cela peut entraîner une augmentation des temps d’attente IPC, en particulier pour les événements IPC:ExecuteGather et IPC:ParallelFinish. Ces problèmes de planification sont souvent dus à des statistiques obsolètes et au gonflement des tables et des index.

Démarrage et arrêt fréquents des applications de travail en parallèle

Les requêtes de courte durée qui déclenchent et interrompent fréquemment des applications de travail en parallèle peuvent entraîner une augmentation du nombre d’événements IPC:BgWorkerStartup et IPC:BgWorkerShutdown. Cela se produit souvent dans les charges de travail OLTP, qui impliquent beaucoup de petites requêtes pouvant être exécutées en parallèle.

Contraintes liées aux ressources

La capacité limitée du processeur, de la mémoire ou des E/S peut entraîner des goulets d’étranglement lors de l’exécution en parallèle, ce qui augmente les temps d’attente pour tous les événements IPC. Par exemple, si le processeur est saturé, les processus de travail peuvent mettre plus de temps à démarrer ou à traiter leur part du travail.

Structures de requête complexes

Les requêtes comportant plusieurs niveaux de parallélisme (jointures en parallèle suivies d’agrégations parallèles, par exemple) peuvent entraîner des modèles IPC plus complexes et des temps d’attente potentiellement accrus, en particulier pour les événements IPC:ExecuteGather.

Ensembles de résultats volumineux

Les requêtes qui génèrent des ensembles de résultats volumineux peuvent entraîner une augmentation des temps d’attente IPC:ExecuteGather, car le processus principal passe plus de temps à collecter et à traiter les résultats des processus de travail.

La compréhension de ces facteurs peut aider à diagnostiquer et à résoudre les problèmes de performances liés à l’exécution de requêtes parallèles dans Aurora PostgreSQL.

Actions

Lorsque vous voyez des temps d’attente liés à une requête parallèle, cela signifie généralement qu’un processus dorsal coordonne ou attend des processus de travail parallèles. Ces temps d’attente sont courants lors de l’exécution de plans en parallèle. Vous pouvez étudier et atténuer l’impact de ces temps d’attente en surveillant l’utilisation des applications de travail en parallèle, en vérifiant les paramètres et en ajustant l’exécution des requêtes et l’allocation des ressources.

Analyse des plans de requêtes pour détecter un parallélisme inefficace

L’exécution de requêtes parallèles peut souvent entraîner une instabilité du système, des pics de processeur et des variations imprévisibles des performances des requêtes. Il est essentiel d’analyser de manière approfondie si le parallélisme améliore réellement votre charge de travail spécifique. Utilisez EXPLAIN ANALYZE pour passer en revue les plans d’exécution de requêtes parallèles.

Désactivez temporairement le parallélisme au niveau de la session pour comparer l’efficacité du plan :


SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;

Réactivez le parallélisme et comparez :


RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE <your_query>;

Si la désactivation du parallélisme donne des résultats meilleurs ou plus cohérents, envisagez de le désactiver pour des requêtes spécifiques au niveau de la session à l’aide des commandes SET. Pour un impact plus large, vous pouvez désactiver le parallélisme au niveau de l’instance en ajustant les paramètres pertinents dans le groupe de paramètres de votre cluster ou de votre instance. Pour plus d’informations, consultez Paramètres Amazon Aurora PostgreSQL..

Surveillance de l’utilisation des requêtes parallèles

Utilisez les requêtes suivantes pour avoir une meilleure visibilité sur l’activité et la capacité des requêtes parallèles :

Vérifiez les processus de travail en parallèle actifs :


SELECT
    COUNT(*)
FROM
    pg_stat_activity
WHERE
    backend_type = 'parallel worker';

Cette requête indique le nombre de processus de travail en parallèle actifs. Une valeur élevée peut indiquer que le paramètre max_parallel_workers est configuré avec une valeur élevée, ce que vous pouvez choisir de réduire.

Vérifiez les requêtes parallèles simultanées :


SELECT
    COUNT(DISTINCT leader_pid)
FROM
    pg_stat_activity
WHERE
    leader_pid IS NOT NULL;

Cette requête renvoie le nombre de processus principaux distincts qui ont lancé des requêtes parallèles. Un nombre élevé indique que plusieurs sessions exécutent des requêtes parallèles simultanément, ce qui peut augmenter la demande en termes de processeur et de mémoire.

Vérification et ajustement des paramètres des requêtes parallèles

Passez en revue les paramètres suivants pour vous assurer qu’ils correspondent à votre charge de travail :

  • max_parallel_workers : nombre total d’applications de travail en parallèle entre toutes les sessions.

  • max_parallel_workers_per_gather : nombre maximum d’applications de travail par requête.

Pour les charges de travail OLAP, l’augmentation de ces valeurs peut améliorer les performances. Pour les charges de travail OLTP, des valeurs plus faibles sont généralement préférées.


SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;

Optimisation de l’allocation des ressources

Surveillez l’utilisation du processeur et envisagez d’ajuster le nombre de processeurs virtuels s’il est constamment élevé et si votre application bénéficie des requêtes parallèles. Assurez-vous que la mémoire disponible est suffisante pour les opérations en parallèle.

  • Utilisez les métriques Performance Insights pour déterminer si le système est lié au processeur.

  • Chaque application de travail en parallèle utilise sa propre work_mem. Assurez-vous que l’utilisation totale de la mémoire respecte les limites de l’instance.

Les requêtes parallèles peuvent consommer beaucoup plus de ressources que les requêtes qui ne sont pas exécutées en parallèle, car chaque processus de travail est un processus complètement distinct qui a à peu près le même impact sur le système qu’une session utilisateur supplémentaire. Cela doit être pris en compte lors du choix d’une valeur pour ce paramètre, ainsi que lors de la configuration des autres paramètres contrôlant l’utilisation des ressources, tels que work_mem. Pour plus d’informations, consultez la documentation sur PostgreSQL. Les limites de ressources telles que work_mem sont appliquées individuellement à chaque application de travail, ce qui signifie que l’utilisation totale peut être beaucoup plus élevée entre tous les processus qu’elle ne le serait normalement pour un seul processus.

Envisagez d’augmenter le nombre de processeurs virtuels ou d’ajuster les paramètres de mémoire si votre charge de travail est fortement parallélisée.

Vérification de la gestion des connexions

En cas de saturation des connexions, passez en revue les stratégies de regroupement des connexions des applications. Envisagez d’implémenter le regroupement de connexions au niveau de l’application s’il n’est pas déjà utilisé.

Vérification et optimisation des opérations de maintenance

Coordonnez la création d’index et les autres tâches de maintenance pour éviter les conflits de ressources. Pensez à planifier ces opérations pendant les heures creuses. Évitez de planifier de lourdes opérations de maintenance (par exemple, des constructions d’index en parallèle) pendant les périodes de forte charge des requêtes utilisateur. Ces opérations peuvent consommer des applications de travail en parallèle et avoir un impact sur les performances des requêtes régulières.

Utilisation de la gestion de plans de requêtes (QPM)

Dans Aurora PostgreSQL, la fonctionnalité de gestion des plans de requêtes (QPM) est conçue pour garantir l’adaptabilité et la stabilité des plans, quelles que soient les modifications apportées à l’environnement de base de données qui peuvent entraîner une régression des plans de requêtes. Pour plus d’informations, consultez Présentation de la gestion des plans de requêtes d’Aurora PostgreSQL. QPM apporte un certain contrôle sur l’optimiseur. Passez en revue les plans approuvés dans QPM pour vous assurer qu’ils correspondent aux paramètres de parallélisme actuels. Mettez à jour ou supprimez les plans obsolètes susceptibles de provoquer une exécution en parallèle sous-optimale.

Vous pouvez également corriger les plans à l’aide de pg_hint_plan. Pour plus d’informations, consultez Correction de plans à l’aide de pg_hint_plan. Vous pouvez utiliser l’indicateur Parallel pour imposer l’exécution en parallèle. Pour plus d’informations, consultez Conseils pour les plans en parallèle.