Vous n'êtes pas identifié(e).
Bonjour,
je souhaite optimiser Postgresql 8.3 et à ce sujet je recherche les valeurs le mieux appropriées pour kernel.shmmax ,shared_buffers,work_mem,max_connexions. Voici quelques informations
Poste :
Pentium(R) Dual-Core CPU E5200 @ 2.50GHz
2Go de Ram
OS :Débian Squeeze (2.6.26-2-686)
sysctl -a | grep kernel.shm | sort
kernel.shmall = 2097152
kernel.shmmax = 33554432
kernel.shmmni = 4096free -k
total used free shared buffers cached
Mem: 2040468 1944932 95536 0 48872 1665340
-/+ buffers/cache: 230720 1809748
Swap: 3903776 836 3902940Dans mon fichier postgresql.conf j'ai actuellement les valeurs suivantes :
max_connections = 100
shared_buffers = 24MB
Je vous remercie d'avance pour votre aide.
Merci
Hors ligne
Bonjour,
pour pouvoir vous aider il nous faudrait plus de renseignement. Est-ce un serveur dédié pour postgresql ? Combien de clients doivent se connecter en simultané ? Y a-t-il des connexions persistantes ou des connexions brêves ? Quelle est l'utilisation de la base ? beaucoup de lecture, beaucoup d'écriture ...
Y a-t-il beaucoup de grosses requêtes (beaucoup de tris, group by sur beaucoup de données)
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
je vais essayé de répondre a vos questions.
- Ce n'est pas un serveur dédié postgresql. En faites ce serveur est dédié au CRM OpenERp + postgresql
- Que voulez vous dire par "clients simultanés"?
-Ce sont plutôt des connexions persistantes.
-Je dirais que l'utilisation est de 50% lecture, 50% ecriture
-Il y a de grosse requête car beaucoup de données
Merci pour vos conseils.
Hors ligne
Que voulez vous dire par "clients simultanés"?
Des connexions à PostgreSQL qui exécutent des requêtes en simultané. Cette information aide à configurer max_connections. Si vous ne savez pas, laissez la valeur par défaut et affinez plus tard si vous le voulez. work_mem dépend aussi du nombre de requêtes exécutées en parallèle. À priori, avec les informations déjà données, je ne dépasserais pas 10 Mo pour l'instant.
De façon très généraliste, une plutôt bonne approximation de shared_buffers est de lui donner 1/4 de la RAM sur un serveur dédié (et donc 1/4 de la RAM consacrée à PostgreSQL sur un serveur non dédié, ce qui semble être votre cas). shmmax doit être au minimum à un peu plus que la valeur de shared_buffers, mais il peut être à beaucoup plus, cela ne changera rien. De toute façon, si shmmax n'est pas suffisamment élevé, PostgreSQL ne pourra pas démarrer, vous trouverez donc rapidement la bonne valeur 
Pour la gestion de la mémoire, cet article (http://www.dalibo.org/glmf107_gestion_m … postgresql) peut vous intéresser. Même s'il commence à dater, les informations qu'il contient sont toujours pertinentes.
Guillaume.
Hors ligne
Merci pour vos informations. Je vais testé cela .
Hors ligne
Sur le même sujet, en reprenant les infos données sur http://www.postgresql.org/docs/current/ … urces.html et partant de la règle selon laquelle
shmmax = taille de la RAM/4
shmall = shmax/ PAGESIZE
pour la config que j'ai
getconfig PAGESIZE j'obtiens 4096
la RAM fait 2 Go soit 2^30.98 arrondi à 2^30 que je divise par 4, ça donne 2^28 = 268435456
et shmall = 2^28/4092 = 65536
en mettant dans postgres.conf
shared_buffer = 268Moet en modifiant les paramètres de kernel comme celà
sysctl -w kernel.shmmax=268435456
sysctl -w kernel.shmall=65536Et bien, ça marche pas. Si je modifie postgres.conf:
shared_buffer = 200MoCa marche. Quelqu'un sait-il ce qui ne va pas?
Hors ligne
Vous avez configuré votre shmmax à 256Mo. Le shmmax est exprimé en octet. Pour prendre 1/4 de la RAM (512 Mo), il faut donc 512*1024*1024=536870912
Dans le doute, pour vérifier le paramétrage vous pouvez utiliser ipcs -l -m. Attention également, en modifiant avec sysctlw -w, votre modification ne sera pas conservée lors d'un redémarrage. Il est préférable de modifier le fichier sysctl.conf et de le recharger (sysctl -p).
Julien.
https://rjuju.github.io/
Hors ligne
J'ai bien modifié sysctl.conf et redémarré à chaque fois.
J'aurais pu mettre plus de shared buffer, mais je que je comprend pas pourquoi si on fixe
shmmax= 2^28 = 268 435 456 soit 268,435 456 millions, et un shared_buffer=268MB alors postgres râle,
alors qu'il ne râle plus avec 200MB.
J'ai l'impression que l'erreur vient du fait de l'approximation que je fais en considérant que 1Mo = 1 000 000 octets != 2^20 = 1 048 576
Si on fait le calcul juste avec shmmax=2^28 on a
shared_buffer = 2^28/2^20 = 2^8 = 256MB
C'est exactement la valeur que donne rjuju
pourtant il râlait avec shared_buffer=250Mo autant et de la même manière qu'avec shared_buffer=268Mo
Finalement, j'ai une solution pour m'en tirer avec shared_buffer=200Mo et j'aimerais comprendre.
Au fait, je suis avec postgres 9.2 et ubuntu precise, mais je ne crois pas que cette info soit très utile.
Je viens de faire un nouveau test en reprenant les valeurs de rjuju:
shmmax=512MBet
kernel.shmmax=536870912
# 2^29
kernel.shmall=131072postgres me donne l'erreur:
DETAIL: Failed system call was shmget(key=5432001, size=572530688, 03600).
il va chercher une mémoire dont la taille est 572530688 est supérieure (de peu) à 2^29
si on change shared_buffer à 500, on a l'erreur:
DETAIL: Failed system call was shmget(key=5432001, size=558759936, 03600).
si on change shared_buffer à 490 on a l'erreur:
DETAIL: Failed system call was shmget(key=5432001, size=547717120, 03600).
si on change shared_buffer à 450 on n'a plus l'erreur!
BYZARRE non?
Dernière modification par ochaussavoine (20/10/2012 12:27:39)
Hors ligne
Tout simplement parce que postgres n'alloue pas que la valeur du shared_buffers dans son segment de mémoire partagée, même si le shared_buffers est la partie la plus importante. Il alloue également le wal_buffers ainsi que de la mémoire pour les connexions, les autovacuum workers etc. Si vous voulez calculer exactement la valeur du shmmax avec vos paramètres, vous pouvez regarder la doc: http://www.postgresql.org/docs/9.2/stat … urces.html (tableau 17-2).
C'est quand même préférable de prévoir largement au-dessus, ça permet de modifier un des paramètres influant sur la taille du segment de mémoire partagée et relancer postgres sans avoir à modifier le shmmax.
Julien.
https://rjuju.github.io/
Hors ligne
Voilà qui est très clair.
Bonne journée Julien et merci de cette réponse.
Hors ligne