Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Marc merci pour l'information ci-dessus,
la surveillance de la mémoire occupée donne-t-elle des résultats?
un espace swap a-t-il étè rajouté?
avec cette surveillance, serait-il possible de connaitre le nombre de requétes en cours?
un utilisateur du SGBD a-t-il des privilèges systèmes élevés? exemple sur un autre moteur SGBDR, il était possible de faire :! une commande unix
A+
JB
Bonsoir,
-le noyau Linux ne se saborde pas, tout à fait d'accord car on a obligatoirement un panic system
-je voudrais savoir si aprés le kill -9 postgresql fonctionne encore,
c'est à dire que le process en cause du kill n'arrète pas le SGBD
-avez-vous évalué la taille mémoire nécessaire pour tous les process du SGBD,
-avez-vous hypotéqué une valeur de shmmax plus grande
les valeurs suivantes dans le noyau Redhat sont-elles changées:
shmmax, shmmin, shmmni, shmseg, semmni, semmsl, semmns, semopm, semvmx,
oui pour shmmax,
A+
JB
4GB de RAM, je pense que l'administrateur système pourrait en préter beaucoup plus!
vous serait-il possible d'observer l'occupation mémoire par:
man vmstat
vmstat 5
ainsi que la variation du swap
référence:
Sep 30 10:56:28 bdserv kernel: Swap cache: add 2215664, delete 2215191, find 350742/524077, race 0+0
Sep 30 10:56:28 bdserv kernel: Out of Memory: Killed process 20741 (postmaster).
une paranthèse, le fichier /var/log/messages fait référence au kill -9
comme c'est une version REDHAT le noyau est bien en 2.6.2x
je ne maitrise pas postgresql mais j'espère que celui-ci gére correctement les derniers blocs mémoire disponible,
je trouve qu'il ne devrait pas se saborder mais tuer le process trés gourmant
A+
JB
Les valeurs par défaut contenues dans le fichier postgresql.conf ont étè altérées?
les valeurs pour les différents debug sont à ?
la dernière valeur un peu dure à avaler le panic!
dans le désordre, l'OS ?
la machine ne sert que pour le SGBD?
la taille mémoire?
un job accounting est en service?
A+
JB
Bonjour,
je fais référence à un autre moteur SGDB,
serait-il possible de connaitre 2 valeurs:
shmmax
taille du file system swap
une aide man sysctl
puis sysctl -a|grep shm
à une certaine époque (retraite), le calcul de la taille du swap était en rapport avec le nombre d'utilisateurs connectés et parfois restant connectés sans activité
le shmmax pouvait atteindre la taille maxi de la RAM toujours avec le swap en conséquense sur une machine dédiée SGBD
A+
JB
Pages : 1