Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Voici ma configuration :
Red Hat Enterprise Linux Server release 6.7 (Santiago)
Overcommit_memory = 0
overcommit_ratio = 50
swappiness = 5
swap = 4Go
RAM = 32
CPU = 20
PostgreSQL 9.3.5
shared_buffer = 8
max_connection = 560
checkpoint_segments=64
Lorsque l'application est fortement utilisée, PostgreSQL swappe, jusqu'à utiliser tout le swap. Puis, il se plante.
Comment faire pour éviter que PostgreSQL ne swappe pas ?
Cordialement
Cécile
Hors ligne
Il manque les unités pour la RAM et le shared_buffers, et il manque la valeur des paramètres work_mem et maintenance_work_mem, pour pouvoir donner un avis.
Guillaume.
Hors ligne
Voici les informations manquantes .
RAM = 32GB
shared_buffer = 8GB
work_mem = 10MB
maintenance_work_mem = 2GB
Merci d'avance.
Hors ligne
Donc a priori, ça devrait tenir. Il s'agit d'un serveur dédié à PostgreSQL ou d'autres applications sont utilisées ? (style jboss, tomcat, etc)
Guillaume.
Hors ligne
Oui. Le serveur est dédié.
Hors ligne
Comme ça, je ne vois aucune raison pour qu'il swappe. La configuration de PostgreSQL semble saine par rapport à la quantité de RAM.
Guillaume.
Hors ligne
Merci pour le retour. Cependant, la question reste posée.
Hors ligne
Bonjour,
Il faudra voir les processus system qui consomment de la ram au moment où ça swap.
Profitez en pour faire le total de conso RAM de vos process postgres pour voir.
Cordialement,
Sébastien.
Hors ligne
Avec top on constate que ce sont les process postgres qui consomment plus de mémoire.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31591 postgres 20 0 8620m 622m 612m R 15.6 1.9 0:07.63 postmaster
24041 postgres 20 0 9268m 7.6g 7.0g S 5.0 24.2 2:49.10 postmaster
24062 postgres 20 0 9268m 7.6g 7.0g D 4.6 24.3 2:50.10 postmaster
31738 postgres 20 0 8620m 161m 153m D 4.6 0.5 0:00.81 postmaster
31583 postgres 20 0 8618m 129m 122m S 4.3 0.4 0:00.69 postmaster
29676 postgres 20 0 8625m 4.4g 4.4g D 3.3 13.9 0:21.46 postmaster
31593 postgres 20 0 8621m 606m 596m D 3.0 1.9 0:02.62 postmaster
31579 postgres 20 0 8618m 108m 101m S 2.3 0.3 0:00.32 postmaster
31586 postgres 20 0 8620m 273m 264m S 1.7 0.9 0:01.32 postmaster
31690 postgres 20 0 8621m 1.1g 1.1g S 1.7 3.6 0:01.19 postmaster
31739 postgres 20 0 8620m 1.1g 1.1g S 1.0 3.6 0:00.90 postmaster
31002 postgres 20 0 8621m 400m 391m S 0.7 1.2 0:02.61 postmaster
31694 postgres 20 0 8617m 32m 28m S 0.7 0.1 0:00.04 postmaster
Hors ligne
par rapport à la RAM disponible sur le serveur, le max connections, le shared_buffers et maintenance work mem
Je pense qu'il faut soir augmenter la RAM, soit baisser les paramètres mémoire au niveau de postgresql.conf.
Cordialement,
Sébastien.
Hors ligne
Le problème de top est qu'il mélange mémoire privée du processus et mémoire partagée (par défaut en tout cas). Du coup, un processus postgres peut prendre 8 Go sans consommer du tout de mémoire (si ce sont bien les 8 Go du shared_buffers). Les processus à 7,6 Go sont certainement là depuis longtemps et ont lu beaucoup de données dans le cache, mais ils ne consomment rien. Un "top -c" indiquerait certainement plus d'informations, ainsi qu'ajouter l'affichage de la colonne DATA.
Guillaume.
Hors ligne
@ruizsebastien : pourquoi ? la valeur de ces paramètres est suffisant pour la mémoire su serveur (8 Go de shared_buffers + 560 * les 10 Mo de work_mem + on va dire 5 fois les 2 Go du maintenance_work_mem nous fait arriver à un peu moins de 24 Go, ce qui laisse encore 9 Go).
Guillaume.
Hors ligne
oui c'est pour ça que je demandais aussi la liste des processus (hors postgres) et ce qu'ils consomment pour voir.
Sans plus d'infos, ce que je proposais était le minimum à faire pour éviter le swap du serveur.
Cordialement,
Sébastien.
Hors ligne
Personnellement j'essaierais avec beaucoup plus de swap, au moins 2 fois la RAM, soit 64GB.
Un swap trop faible fait que le noyau ne peut pas décharger les pages qui ne lui servent pas dans l'immédiat. Du coup il est obligé de swapper plus fréquemment, ce qui aggrave le problème du point de vue de l'utilisateur.
Un autre aspect du problème est que la consommation de RAM dépend des requêtes. Certaines requêtes peuvent être gourmandes. En principe les opérations de jointure, hachage etc...sont capables d'écrire des données temporaires sur disque quand work_mem est dépassé. Mais il peut aussi se tromper dans l'estimation de la mémoire nécessaire et allouer beaucoup plus que prévu. Pour cet aspect-là il faut regarder quelles sont les requêtes en exécution quand les problèmes surviennent et étudier leur conso réelle avec EXPLAIN ANALYZE (commencer peut-être par auto_explain).
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pages : 1
