IPC : événements d'attente parallèles - Amazon Relational Database Service
Versions de moteur prises en chargeContexteCauses probables de l'allongement des temps 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 : événements d'attente parallèles

Les informations suivantes IPC:parallel wait events indiquent qu'une session attend une communication inter-processus liée aux opérations d'exécution de requêtes en parallèle.

  • 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 travailleurs pour l'exécution de requêtes en parallèle.

  • IPC:BgWorkerShutdown- Un processus attend qu'un processus de travail parallèle termine sa séquence d'arrêt. Cela se produit pendant la phase de nettoyage de l'exécution parallèle des requêtes.

  • IPC:ExecuteGather- Un processus attend de recevoir des données provenant de processus de travail parallèles pendant l'exécution de la requête. Cela se produit lorsque le processus leader doit recueillir des résultats auprès de ses employés.

  • IPC:ParallelFinish- Un processus attend que les travailleurs parallèles terminent leur exécution et publient leurs résultats finaux. Cela se produit pendant la phase d'achèvement de l'exécution parallèle des requêtes.

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 parallèle de requêtes dans PostgreSQL implique la collaboration de plusieurs processus pour traiter une seule requête. Lorsqu'une requête est jugée appropriée pour la parallélisation, un processus leader est coordonné avec un ou plusieurs processus de travail parallèle sur la base du réglage des max_parallel_workers_per_gather paramètres. Le processus du leader répartit le travail entre les travailleurs, chaque travailleur traite sa partie des données de manière indépendante et les résultats sont transmis au processus du leader.

Note

Chaque travailleur parallèle fonctionne comme un processus distinct dont les besoins en ressources sont similaires à ceux d'une session utilisateur complète. Cela signifie qu'une requête parallèle avec 4 travailleurs peut consommer jusqu'à 5 fois plus de ressources (processeur, mémoire, I/O bande passante) par rapport à une requête non 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 travailleur, multipliant potentiellement l'utilisation totale de la mémoire entre tous les processus.

L'architecture de requêtes parallèles comprend trois composants principaux :

  • Processus leader : processus principal qui initie l'opération parallèle, divise 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 en parallèle.

  • Fusion Gather/Gather : opérations qui combinent les résultats de plusieurs processus de travail jusqu'au leader

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

  • Démarrage du travailleur : lorsque des travailleurs parallèles sont initialisés

  • Échange de données : lorsque les travailleurs traitent les données et envoient les résultats au responsable

  • Arrêt du programme de travail : lorsque l'exécution parallèle est terminée et que les travailleurs sont interrompus

  • 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 diagnostiquer les problèmes de performances liés à l'exécution parallèle de requêtes, en particulier dans les environnements à forte concurrence dans lesquels plusieurs requêtes parallèles peuvent s'exécuter simultanément.

Causes probables de l'allongement des temps d'attente

Plusieurs facteurs peuvent contribuer à augmenter le nombre d'événements d'attente IPC liés au parallèle :

Haute simultanéité 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 comportant 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 parallèles inefficaces, cela peut entraîner une parallélisation inutile ou une mauvaise répartition du travail entre les employés. Cela peut entraîner une augmentation des temps d'attente pour l'IPC, en particulier pour les événements IPC:ExecuteGather et IPC:ParallelFinish les événements. Ces problèmes de planification sont souvent dus à des statistiques périmées et table/index à des excès.

Démarrage et arrêt fréquents des travailleurs parallèles

Les requêtes de courte durée qui déclenchent et interrompent fréquemment des tâches parallèles peuvent entraîner une augmentation du nombre IPC:BgWorkerStartup d'IPC:BgWorkerShutdownévénements. Cela se produit souvent dans les charges de travail OLTP comportant de nombreuses petites requêtes parallélisables.

Contraintes liées aux ressources

Un processeur, une mémoire ou une I/O capacité limités peuvent entraîner des blocages 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 prendre plus de temps à démarrer ou à traiter leur partie du travail.

Structures de requêtes complexes

Les requêtes comportant plusieurs niveaux de parallélisme (par exemple, des jointures parallèles suivies d'agrégations parallèles) 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 produisent de grands ensembles de résultats peuvent entraîner une augmentation des temps d'IPC:ExecuteGatherattente, 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 parallèle de requêtes 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 principal coordonne ou attend des processus de travail parallèles. Ces temps d'attente sont courants lors de l'exécution de plans parallèles. Vous pouvez étudier et atténuer l'impact de ces temps d'attente en surveillant l'utilisation des travailleurs parallèles, en revoyant les paramètres et en ajustant l'exécution des requêtes et l'allocation des ressources.

Analyser les plans de requêtes pour détecter un parallélisme inefficace

L'exécution parallèle de requêtes 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 votre groupe de paramètres de base de données. Pour de plus amples informations, veuillez consulter Modification des paramètres d'un groupe de paramètres de base de données dans Amazon RDS ( Aurora).

Surveiller 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 parallèle actifs :


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

Cette requête indique le nombre de processus de travail parallèle actifs. Une valeur élevée peut indiquer que votre `max_parallel_workers` est configuré avec une valeur élevée et vous pourriez envisager de la 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 leaders 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érifiez et ajustez les 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 de travailleurs parallèles au cours de toutes les sessions.

  • max_parallel_workers_per_gather: Nombre maximum de travailleurs 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, les valeurs les 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 v CPUs s'il est constamment élevé et si votre application bénéficie de requêtes parallèles. Assurez-vous que la mémoire disponible est suffisante pour les opérations parallèles.

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

  • Chaque parallel worker utilise le sienwork_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 non parallèles, 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 d'autres paramètres contrôlant l'utilisation des ressources, tels quework_mem. Pour de plus amples informations, veuillez consulter la documentation sur PostgreSQL. Les limites de ressources telles que celles qui work_mem sont appliquées individuellement à chaque travailleur, ce qui signifie que l'utilisation totale peut être beaucoup plus élevée dans tous les processus qu'elle ne le serait normalement pour un seul processus.

Envisagez d'augmenter v CPUs ou de régler les paramètres de mémoire si votre charge de travail est fortement parallélisée.

Étudier la gestion des connexions

En cas d'épuisement 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é.

Passez en revue et optimisez les opérations de maintenance

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