Postgresql 10 - Configuration parallèle
Il existe 4 configurations pour activer le parallèle et faire l'optimisation, mais la documentation de PostgreSQL ne dit rien sur les valeurs ou le calcul. Mes questions sont:
1- Comment calculer les valeurs de
max_parallel_workers,max_parallel_workers_per_gatheretmax_worker_processes?2- Le
work_mempeut être calculé sur la base des connexions et de la mémoire (RAM), mais lework_memdoit changer quelque chose si j'active le parallèle?
Ma supposition est: si la machine a 8 cœurs the max_parallel_workers est 8 et les valeurs de processus de travail et par regroupement sont 32 (8 * 4), le nombre 4 que j'ai pris dans la configuration d'origine qui est de 4 regroupements pour 1 travail parallèle.
Après quelques recherches, j'ai trouvé quelques réponses, cela peut aider ceux qui veulent activer et avoir une configuration de base, au cas où vous auriez 4 cœurs (CPU):
vos processus de travail max seront la quantité de cœurs et le parallèle max doit avoir la même quantité:
max_worker_processes = 4
max_parallel_workers = 4
la collecte est plus complexe car cette valeur peut être manipulée en fonction de vos besoins et de vos ressources, il est nécessaire de tester pour obtenir la meilleure valeur, mais pour les valeurs de démarrage, vous pouvez utiliser cores/2.
max_parallel_workers_per_gather = 2
Ce n'est pas une réponse définitive, il y a des points manquants ... Je suis toujours en train de chercher et de mettre à jour cette réponse ou j'attends une meilleure.
La question est assez évidente, mais la réponse ne l'est pas.
Je vais essayer de décrire est un peu plus large, donc si quelque chose vous semble évident - sautez-le.
Tout d'abord - comment cela fonctionne est décrit ici ici . À quoi servent ces paramètres est décrit ici . En d'autres termes - PG a un pool de processus qui peuvent faire quelque chose en arrière-plan. Le nombre maximum d'entre eux est limité par max_worker_processes. Lorsque l'analyse de table est effectuée, cela peut prendre beaucoup de temps, il serait donc judicieux d'avoir plus de processus qui prennent des données. Cela peut être fait en arrière-plan, par ... des travailleurs de fond. Les nœuds de plan de requête qui peuvent être effectués par eux sont: gather, gather-merge.
Chaque travailleur en arrière-plan a sa mémoire - pour le tri et d'autres choses liées à l'exécution. Ils sont là tout le temps, il vaut donc mieux avoir cela à l'esprit, juste pour être sûr que le système n'utilise pas le swap ...
Par ailleurs. Essayez de trouver le meilleur nombre de travailleurs par requête - par défaut, c'est 2. Donc, si tout fonctionne correctement, deux travailleurs en arrière-plan sont utilisés pour collecter les données. La question suivante est de savoir combien de requêtes sont exécutées en parallèle. Je veux dire - que les requêtes lourdes qui nécessitent un traitement parallèle. Ayant ces deux chiffres à dire - 4 travailleurs par requête et 10 requêtes - il y a 40 travailleurs nécessaires, seulement pour cela. Vous pouvez calculer si c'est OK ou expérimenter cela. De cette façon ou de l'autre - il y a un paramètre de plus - max_worker_processes. Avoir ces 40 employés pour le traitement parallèle - vous avez besoin de plus d'employés pour d'autres tâches - comme la réplication.
Est-ce que 40 sons sont raisonnables? Il y a deux contre-points ici - par défaut, PG est OLTP. Le système est donc préparé pour autre chose, et ce type de changement peut apporter de bons résultats. Par contre - il y a un bgwriter, donc après tout, il y a un processus qui traite des entrées/sorties. Il repose sur le système, mais quand même, un processus.
La réponse est donc loin d'être parfaite - vous devez essayer, collecter vos propres statistiques et décider.
Il existe un joli petit utilitaire de configuration en ligne qui permet de définir les principales valeurs de postgresql.conf.
Ce n'est pas parfait mais cela donne un point de départ qui peut être utile.