Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Optimisation » Eviter de Swapper, mieux utiliser la Ram » 30/09/2010 17:37:34
Etant donné qu'on fait ce qu'on peut pour éviter d'etre à cours de RAM en optimisant nos parametres postgresql.conf, le swappiness est donc une chose qui ne sera probablement pas utilisée alors.
Merci en tout cas pour vos réponses!
#2 Re : Optimisation » Eviter de Swapper, mieux utiliser la Ram » 30/09/2010 15:53:13
J'ai pas mal cherché et je n'ai pas vraiment trouvé mon bonheur, effectivement.
Il y a bien un article ici mais le schéma final est sommaire (bien que l'article soit trés instructif).
Concernant la swappiness dont nous parlions au début, ne serait-il pas judicieux de ne pas la laisser à 60 sur un serveur dédié à postgres, de manière à mettre le maximum en mémoire vive?
Est-ce une pratique que vous encouragez? J'ai vu que pour un systeme Linux il y a plusieurs écoles à ce sujet mais pour un serveur dédié postgres, la réponse est peut etre plus tranchée..
Cordialement,
Olivier B.
#3 Re : Optimisation » Eviter de Swapper, mieux utiliser la Ram » 30/09/2010 12:22:26
Merci pour vos explications.
Les choses s'éclaircissent un peu plus dans ma tête.
Savez-vous, pour terminer, si un schéma expliquant le fonctionnement détaillé l'utilisation mémoire a déjà été fait ?
Cordialement,
Olivier B.
#4 Re : Optimisation » Eviter de Swapper, mieux utiliser la Ram » 29/09/2010 15:32:22
Merci pour votre réponse.
J'ai testé un work_mem à 5MB dans l'un de mes tests mais j'avais une forte utilisation des fichiers de pgsql_tmp donc j'ai pensé augmenter cette valeur.
L'analyse des logs donne à la même seconde, pour le meme utilisateur, une vingtaine de lignes comme celle-ci:
2010-09-29 12:08:21 CEST -- toto : LOG: fichier temporaire : chemin « base/pgsql_tmp/pgsql_tmp5405.350 », taille 1910352
J'ai fais en gros les calculs ainsi: 1,9MB*20=38MB, ça me semblait beaucoup (300 clients, on a vite fais d'avoir pas mal de requetes simultanées), j'ai donc mis 20 pour limiter le nombre d'ecritures dans ce repertoire psql_tmp
Là ca tourne pas mal donc tant mieux, maintenant si vous pensez que c'est une erreur, je le baisserai.
Depuis que j'ai diminué mon shared_mem de 2500 à 1500 les choses vont déjà mieux. Il y a un fort interet à utiliser plus de 1GB pour la shared_mem? Parce que finalement, je me dis que si cette valeur ne concerne pas les clients, je peux la baisser comme vous dites pour attribuer d'avantage de mémoire aux autres opérations.
Pour le point 3) , augmenter la taille de mes wal_buffer à 1Mo aura comme conséquences que mon serveur en warm standby recevra les wal moins souvent mais de plus grande taille non?
De plus, si je comprend, c'est mon shared_buffer qui donne l'espace pour mes wal.
Cependant, si checkpoint_segment est à 10, c'est donc que je vais ecrire mes wal sur le disque tous les 16Mo*10=160Mo de wal non (si on oublie la contrainte de timeout)?
Finalement, quel est l'interet (si vous le suggerez c'est qu'il y en a un j'imagine) d'avoir des 160 wals de 1Mo plutot que 8 fois plus de wal de 256ko?
Olivier B
#5 Optimisation » Eviter de Swapper, mieux utiliser la Ram » 29/09/2010 14:32:03
- oliver07b
- Réponses : 10
Bonjour,
J'utilise Postgres 8.4.4 sur un serveur en production (Debian Lenny avec 4Go de RAM) sur lequel j'ai environ 300 connexions simultanées et sur lequel j'ai activé l'archive mode (warm standby sur un autre serveur).
Je n'avais pas de soucis jusqu'à présent mais depuis peu mon serveur s'est mis à utiliser la swap sans pour autant utiliser la RAM à fond.
Voici les paramètres de mon poste:
Coté sysctl:
swappiness est à 60.
kernel.shmmax=3758096384
kernel.shmall=3758096384
vm.overcommit_memory=2
Coté postgresql.conf
shared_buffers = 2560MB
work_mem = 10MB
maintenance_work_mem = 256MB
checkpoint_segments = 20
effective_cache_size = 4GB
Dans un premier temps j'ai basculé comme ceci:
Coté sysctl:
swappiness est à 80.
Les problèmes ont continués, j'ai donc fait ceci:
Coté postgresql.conf
shared_buffers = 1560MB
work_mem = 5MB
maintenance_work_mem = 128MB
checkpoint_segments = 10
Je n'ai alors plus eu de probleme de swap...
Du coups j'ai rebasculé ainsi:
Coté sysctl:
swappiness est à 60.
Coté postgresql.conf
[color=blue]shared_buffers = 1560MB
work_mem = 20MB (jai eu pas mal de fichiers tmp de créés quand j'étais à 5MB)
maintenance_work_mem = 256MB
checkpoint_segments = 10
Et la swap ne m'embête plus.
Je devrais être content sauf que je ne comprends pas bien ce qui a pu se passer.
Je pense que je ne maitrise pas la gestion de la mémoire sous postgres: J'ai 4Go de RAM, je ne veux pas swapper: mes valeurs semblent elles correctes?Je sais que trop mettre de shared_buffer peut finir par être néfaste.
Mais finalement mes question sont
1) shared_buffer définie-t-il le max de mémoire que peut prendre postgres dans sa globalité (work_mem + maintenance_mem + cœur de postgres + ...)?
2) Dans ma tete, en ce moment, je pense ainsi: postgres utilise:
shared_buffer + work_mem * (nombre d'opérations de tri,... à l'instant t) + (maintenance_worker qui tournent à l'instant t) * maintenance_work_mem
Suis-je à peu prés juste?
3) checkpoint_segment peut-il jouer sur l'utilisation de la ram? est-ce que postgres alloue cela dans le shared_mem ou bien est-ce en plus du shared_mem?
4) En gros, le shared mem est il seulement de la mémoire vive, et que comprend-il?
Je me suis pas mal documenté mais j'avoue ne pas vraiment bien faire le lien entre tous ces points... désolé si je suis un peu confus.
Merci pour votre lecture de ce post.
Olivier B.
Pages : 1