Meilleures pratiques pour les requêtes parallèles dans Aurora PostgreSQL RDS pour

L'exécution parallèle de requêtes est une fonctionnalité de PostgreSQL qui permet de diviser une seule requête SQL en tâches plus petites traitées simultanément par plusieurs processus de travail en arrière-plan. Au lieu d'exécuter une requête entièrement dans un seul processus principal, PostgreSQL peut répartir certaines parties de la requête, telles que les scans, les jointures, les agrégations ou le tri, sur plusieurs cœurs de processeur. Le processus leader coordonne cette exécution et recueille les résultats auprès des travailleurs parallèles.

Toutefois, pour la plupart des charges de travail de production, en particulier les systèmes OLTP à haute simultanéité, nous recommandons de désactiver l'exécution automatique des requêtes en parallèle. Bien que le parallélisme puisse accélérer les requêtes sur de grands ensembles de données dans le cadre des charges de travail d'analyse ou de reporting, il présente des risques importants qui l'emportent souvent sur les avantages dans les environnements de production chargés.

L'exécution parallèle entraîne également une surcharge importante. Chaque parallel worker est un processus principal de PostgreSQL complet, qui nécessite une bifurcation des processus (copie des structures de mémoire et initialisation de l'état du processus) et une authentification (consommation d'emplacements de connexion supérieurs à votre limite). max_connections Chaque travailleur consomme également sa propre mémoire, notamment work_mem pour les opérations de tri et de hachage, avec plusieurs travailleurs par requête, l'utilisation de la mémoire se multiplie rapidement (par exemple, 4 travailleurs × 64 Mo work_mem = 256 Mo par requête). Par conséquent, les requêtes parallèles peuvent consommer beaucoup plus de ressources système que les requêtes à processus unique. S'ils ne sont pas correctement réglés, ils peuvent entraîner une saturation du processeur (plusieurs travailleurs surchargent la capacité de traitement disponible), une augmentation du changement de contexte (le système d'exploitation passe fréquemment d'un processus de travail à un autre, augmente la charge de travail et réduit le débit) ou un épuisement des connexions (chaque travailleur parallèle occupe un emplacement de connexion, une requête avec 4 travailleurs au total, ce qui peut rapidement épuiser votre pool de connexions en cas de forte simultanéité, empêchant de nouvelles connexions clients et provoquant des défaillances d'applications). Ces problèmes sont particulièrement graves dans le cas de charges de travail hautement simultanées où plusieurs requêtes peuvent tenter une exécution parallèle simultanément.

PostgreSQL décide d'utiliser ou non le parallélisme en fonction des estimations de coûts. Dans certains cas, le planificateur peut automatiquement passer à un plan parallèle s'il semble moins cher, même si ce n'est pas l'idéal dans la pratique. Cela peut se produire si les statistiques d'index ne sont plus à jour ou si le surcroît de données rend les scans séquentiels plus attrayants que les recherches d'index. En raison de ce comportement, les plans parallèles automatiques peuvent parfois entraîner des régressions au niveau des performances des requêtes ou de la stabilité du système.

Pour tirer le meilleur parti des requêtes parallèles dans Aurora PostgreSQL , il est important de les tester et de les ajuster en fonction de votre charge de travail, de surveiller l'impact sur le système et de désactiver la sélection automatique des plans parallèles au profit du contrôle au niveau des requêtes.

Paramètres de configuration

PostgreSQL utilise plusieurs paramètres pour contrôler le comportement et la disponibilité des requêtes parallèles. Il est essentiel de les comprendre et de les ajuster pour obtenir des performances prévisibles :

Paramètre	Description	Par défaut
max_parallel_workers	Nombre maximum de processus de travail en arrière-plan pouvant être exécutés au total	MEILLEUR ($ DBInstance VCPU/2,8)
max_parallel_workers_per_gather	Nombre maximum de travailleurs par nœud du plan de requête (par exemple, parGather)	2
parallel_setup_cost	Coût du planificateur ajouté pour le lancement d'une infrastructure de requêtes parallèles	1 000
parallel_tuple_cost	Coût par tuple traité en mode parallèle (influence la décision du planificateur)	0.1
force_parallel_mode	Force le planificateur à tester des plans parallèles (off,on,regress)	off

Considérations clés

• max_parallel_workerscontrôle le pool total de travailleurs parallèles. Si cette valeur est trop faible, certaines requêtes peuvent revenir à l'exécution en série.

• max_parallel_workers_per_gatheraffecte le nombre de travailleurs qu'une seule requête peut utiliser. Une valeur plus élevée augmente la simultanéité, mais également l'utilisation des ressources.

• parallel_setup_costet parallel_tuple_cost affectent le modèle de coûts du planificateur. En les abaissant, les plans parallèles sont plus susceptibles d'être choisis.

• force_parallel_modeest utile pour les tests mais ne doit pas être utilisé en production sauf si cela est nécessaire.

Note

La valeur par défaut du max_parallel_workers paramètre est calculée dynamiquement en fonction de la taille de l'instance à l'aide de la formuleGREATEST($DBInstanceVCPU/2, 8). Cela signifie que lorsque vous adaptez votre instance de base de données d' Aurora à une taille de calcul plus grande avec plus de vCPUs, le nombre maximum de travailleurs parallèles disponibles augmente automatiquement. Par conséquent, les requêtes précédemment exécutées en série ou avec un parallélisme limité peuvent soudainement utiliser davantage de travailleurs parallèles après une opération de mise à l'échelle, ce qui peut entraîner une augmentation inattendue de l'utilisation des connexions, de l'utilisation du processeur et de la consommation de mémoire. Il est important de surveiller le comportement des requêtes parallèles après tout événement de dimensionnement du calcul et de les ajuster max_parallel_workers_per_gather si nécessaire pour garantir une utilisation prévisible des ressources.

Identifier l'utilisation des requêtes parallèles

Les requêtes peuvent passer à des plans parallèles en fonction de la distribution des données ou des statistiques. Par exemple :

SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';

Cette requête peut utiliser un index pour les données récentes, mais passer à un scan séquentiel parallèle pour les données historiques.

Vous pouvez enregistrer les plans d'exécution des requêtes en chargeant le auto_explain module. Pour en savoir plus, consultez la section Enregistrement des plans d'exécution des requêtes dans le centre de AWS connaissances.

Vous pouvez surveiller les plans d'exécution des requêtes dans votre instance de base de données Aurora PostgreSQL afin de détecter les plans d'exécution qui contribuent à la charge actuelle de la base de données et de suivre les statistiques de performance des plans d'exécution au fil du temps à l'aide de ce paramètre. aurora_compute_plan_id Pour en savoir plus, consultez la section Surveillance des plans d'exécution des requêtes et de la mémoire maximale pour Aurora PostgreSQL

Vous pouvez surveiller CloudWatch Database Insights pour détecter les événements d'attente liés aux requêtes parallèles. Pour en savoir plus sur les événements d'attente liés à Parallel Query, consultez IPC:Parallel wait events

À partir de la version 18 de PostgreSQL, vous pouvez surveiller l'activité des travailleurs parallèles à l'aide de nouvelles colonnes dans et : pg_stat_databasepg_stat_statements

• parallel_workers_to_launch: Nombre de travailleurs parallèles dont le lancement est prévu

• parallel_workers_launched: Nombre de travailleurs parallèles réellement lancés

Ces mesures permettent d'identifier les écarts entre le parallélisme prévu et le parallélisme réel, ce qui peut indiquer des contraintes de ressources ou des problèmes de configuration. Utilisez les requêtes suivantes pour surveiller l'exécution parallèle :

Pour les métriques de travail parallèle au niveau de la base de données :

SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();

Pour les métriques de travail parallèle au niveau de la requête

SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;

Comment contrôler le parallélisme

Il existe plusieurs méthodes pour contrôler le parallélisme des requêtes, chacune étant conçue pour différents scénarios et exigences.

Pour désactiver le parallélisme automatique de manière globale, modifiez votre groupe  :

max_parallel_workers_per_gather = 0;

Pour les paramètres persistants spécifiques à l'utilisateur, la commande ALTER ROLE permet de définir des paramètres qui s'appliqueront à toutes les futures sessions d'un utilisateur en particulier.

Par exemple :

ALTER ROLE username SET max_parallel_workers_per_gather = 4;garantit que chaque fois que cet utilisateur se connecte à la base de données, ses sessions utilisent ce paramètre de travail parallèle lorsque cela est nécessaire.

Le contrôle au niveau de la session peut être réalisé à l'aide de la commande SET, qui modifie les paramètres pendant la durée de la session de base de données en cours. Cela est particulièrement utile lorsque vous devez ajuster temporairement les paramètres sans affecter les autres utilisateurs ou les sessions futures. Une fois définis, ces paramètres restent actifs jusqu'à ce qu'ils soient explicitement réinitialisés ou jusqu'à la fin de la session. Les commandes sont simples :

SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;

Pour un contrôle encore plus précis, SET LOCAL vous permet de modifier les paramètres d'une seule transaction. C'est idéal lorsque vous devez ajuster les paramètres d'un ensemble spécifique de requêtes au sein d'une transaction, après quoi les paramètres reviennent automatiquement à leurs valeurs précédentes. Cette approche permet d'éviter des effets indésirables sur les autres opérations au cours de la même session.

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 la section Présentation de la gestion des plans de requêtes 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 Corriger des 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.

Diagnostic du comportement des requêtes parallèles

EXPLAIN (ANALYZE, VERBOSE)À utiliser pour vérifier si une requête a utilisé l'exécution parallèle :

• Recherchez des nœuds tels que GatherGather Merge, ouParallel Seq Scan.

• Comparez les forfaits avec et sans parallélisme.

Pour désactiver temporairement le parallélisme à des fins de comparaison :

SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;
RESET max_parallel_workers_per_gather;