Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'aimerais savoir quelle est la taille maximale que peut occuper en mémoire un process backend ? Je connais les paramètres work_mem, maintenance_work_mem et temp_buffers.
Mais que se passe t'il si je lance une requête qui ramène 5 Go de données ? Et pour corser le tout cette requête possède de nombreux noeuds d'exécution.
Est ce que l'exécuteur stocke les infos en mémoire ou bien les envoie t'il en "flux" au client ?
Merci
PS: J'espère que ma question est assez claire :s
Hors ligne
Bonjour,
Je peux emmener juste une partie de la réponse, notre spécialiste du moteur PostgreSQL (Gleu) complétera certainement.
Votre requête va utiliser une ou plusieurs zone de mémoire :
shared_buffer pour les blocs de données en RAM
work_mem pour les tris.
Les zone mémoires sont utilisées à concurrence de ce que vous avez fixé dans postgresql.conf.
Si il y a besoin de plus de mémoire (pour les tris) il y aura production de fichiers temporaire sur disque.
Le danger avec work_mem c'est d'exploser la RAM si ce paramètre est trop élevé (risque de swap) ou de créer trop de fichiers sur disque si trop bas.
La est toute la difficulté.
Cordialement.
Cordialement,
Sébastien.
Hors ligne
Je me pose a question au niveau de la résolution des jointures des plans d'exécution. Par exemple les hash join et merge join vont s'exécuter dans la work_mem.... mais le nested join ? Il n'y a pas de tri, juste deux boucles imbriquées. De ce que je comprends, ça doit être au niveau de l'exécuteur du backend.
Dernière modification par pitpoule (10/01/2018 16:49:16)
Hors ligne
bonjour pitpoule,
Il y a une instance de work_mem utilisée par nœud de requête, donc, une requête avec un JOIN va utiliser 2 work_mem, un tri utilise un work_mem de plus, et ainsi de suite.
Le danger d'un work_mem trop élevé ce n'est pas seulement de faire du swap, c'est de se retrouver avec un oom-killer qui peux tuer le processus postmaster de postgres, ce qui peut entraîner des corruptions de données.
Pour s'en protéger, configurer
vm.overcommit_ratio
avec
vm.overcommit_memory = 2
définir vm.overcommit_ratio en suivant la formule suivante :
overcommit_ratio=target_ratio-(100/TOTAL RAM)*SWAP SIZE
target_ratio à 90 pour 90% est une valeur raisonnable.
Hors ligne
Je précise que le déclenchement de l'OOM killer peut tuer brutalement le postmaster, mais cela ne corrompra pas l'instance. Par contre arrêt de service, perte du cache etc.
Julien.
https://rjuju.github.io/
Hors ligne
pitpoule, pas besoin de mémoire pour un Nested Loop. Comme vous le dites, ce sont deux boucles imbriquées parcourues en même temps. Le backend a besoin de garder en mémoire uniquement la ligne en cours de traitement pour la la relation externe (et encore, elle est dans le cache). Donc non, vraiment aucune mémoire spécifique.
Guillaume.
Hors ligne
pitpoule, pas besoin de mémoire pour un Nested Loop. Comme vous le dites, ce sont deux boucles imbriquées parcourues en même temps. Le backend a besoin de garder en mémoire uniquement la ligne en cours de traitement pour la la relation externe (et encore, elle est dans le cache). Donc non, vraiment aucune mémoire spécifique.
Donc la taille mémoire utilisée par un backend ne dépendra que des valeurs de work_mem, temp_buffers et maintenance_work_mem ?
Hors ligne
Non, mais on n'a pas d'autres moyens de l'estimer.
Guillaume.
Hors ligne
Ah.... du coup, j'en reviens à mon post initial... qu'est ce qui occupe de la mémoire au niveau du backend ? (en dehors de work_mem, maintenance_work_mem et temp_buffers ?
Hors ligne
shared_buffers
wal_buffers
autovacuum_work_mem
Cordialement,
Sébastien.
Hors ligne
shared_buffers et wal_buffers ne prennent pas de mémoire locale pour le backend. Le backend peut les utiliser mais c'est de la mémoire partagée.
Quant à la question initiale, il n'y a pas de paramètre pour le reste.
Guillaume.
Hors ligne
Pages : 1
