Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
J'ai une BD de production en PostgreSQL 8.1.2 sous White Box 4.
Je rencontre le message d'erreur ci-dessous lors de l'exécution d'un script qui effectue les tâches suivantes :
vacuumdb -a -f -z
reindexdb -a
reindexdb -s
2011-04-03 12:48:51 CSTERROR: out of memory
2011-04-03 12:48:51 CSTDETAIL: Failed on request of size 67108864.
2011-04-03 12:48:51 CSTSTATEMENT: REINDEX DATABASE geo;
La machine dispose de :
MemTotal: 2075012 kB (grep MemTotal /proc/meminfo)
SwapTotal: 4096564 kB (grep SwapTotal /proc/meminfo)
Quelle peut être la source du problème ?
Merci pour vos réponses.
Hors ligne
Votre configuration de PostgreSQL peut être un problème. Quel est la valeur des paramètres shared_buffers, work_mem, maintenance_work_mem et max_connections ?
L'utilisation du serveur par d'autres applications peut être un problème. Est-ce un serveur dédié à PostgreSQL ?
Guillaume.
Hors ligne
Bonjour Guillaume,
Les valeurs des paramètres sont :
shared_buffers=50000
work_mem=1024000
maintenance_work_mem=1024000
max_connections=100
Oui le serveur est dédié à PostgreSQL.
Merci pour votre aide.
Hors ligne
Sans unité, shared_buffers est un nombre de blocs de 8 Ko alors que work_mem et maintenance_work_mem sont en Ko. Autrement dit, vous autorisez PostgreSQL à accaparer : 50000*8ko+100*1024000*1ko, soit seulement 98 Go. J'espère que vous avez beaucoup de mémoire sur le serveur 
Bref, ça vous fait 332 Mo de shared_buffers, ce qui n'est pas délirant. 1 Go pour work_mem, ça, par contre, c'est du délire Le descendre à quelque chose entre 10 et 50 Mo (et plutôt 10 que 50). Quant à maintenance_work_mem, 256 Mo devrait suffire. Ce qui vous donne un total de 332+10*100, soit 1,3Go. Ce qui est plus réaliste, même avec un VACUUM en même temps.
PS : j'ai fait l'impasse sur le fait qu'un processus peut utiliser plusieurs fois work_mem, mais avec une valeur de 10 Mo, cela devrait passer sans problème.
Guillaume.
Hors ligne
Ok effectivement les paramètres sont loin d'être ceux préconisé dans l'article de LinuxMag 131 que j'ai lu.
Je vais planifier un arrêt/modification des paramètres/redémarrage du serveur.
Je vous ferai part des résultat aprés modif et exécution du script posant problème.
Merci pour votre aide.
Hors ligne
Bonjour,
Interpellé par ce thread, j'ai jeté un coup d'oeil à mon propre fichier de configuration (sous CentOS).
J'y lis des valeurs telles que:
- shared_buffers = 7680MB
- maintenance_work_mem = 1GB
etc...
A priori, ces paramètres avec unités semblent licites et, sous réserve que ce soit bien la cas, moins sujet à erreurs d'interprétations que des simples valeurs numériques
Hors ligne
Oui, c'est la «bonne» façon de les préciser depuis que PostgreSQL supporte les unités dans les fichiers de configuration.
Marc.
Hors ligne
Bonjour,
effectivement il faut preciser les units, c'est bcp plus limpide.
pour y voir plus clair encore pouvez vous me donner votre config pour les 5 champs suivants
avec la capacité totale en RAM de votre bécane
voici la mienne : total 4096 G0 RAM
- work_mem =1024MB
- maintenance_work_mem =512MB
- shared_buffers = 2048MB
- temp_buffers = 512MB
- max_prepared_transactions = 10
Merci à tous
je confirme http://www.dalibo.com est très bien fait
Hors ligne
work_mem est bien trop haut. Il suffirait de quatre utilisateurs avec de grosses requêtes pour écrouler le serveur. temp_buffers est aussi bien trop gros. max_prepared_transactions, je ne l'ai jamais vu activé où que ce soit. Vous utilisez Java XA ?
Guillaume.
Hors ligne
non j'utilise pas JAVA XA,
j'ai fait une erreur, j'ai 8Go de RAM au total
qu'est ce que vous me conseillez,
à vrai dire je pourrais ne mettre que 5 ou 6 users
pour le max_prepared_transactions je vais le commentez, pour le reste j'attend de vos nouvelles,
merci pour votre précédente réponse
Hors ligne
Pour un serveur dédié, je dirais 2 Go de shared_buffers, 10 Mo de work_mem, 512 Mo de maintenance_work_mem, 0 pour max_prepared_transactions. Mais bon, sans en savoir plus sur l'utilisateur du serveur, c'est un peu de la divination...
Guillaume.
Hors ligne
je fais des tests mais apperemment le plus rapide avec 8Go de Ram c'est :
- work_mem =1024MB
- maintenance_work_mem =512MB
- shared_buffers = 2048MB
- temp_buffers = 512MB
la charge n'étant pas énorme, ca devrait aller, sinon je baisserai le work_mem
merci pour la discussion
Hors ligne
Ok. Mais le work_mem aussi élevé, c'est presque la garantie d'avoir des problèmes de mémoire assez rapidement. Voire un serveur qui s'effondre totalement (à court de swap)
Marc.
Hors ligne
ok je prends note
je vais me contenter de 512MB
enfin si c'est pas encore trop ...
merci pour vos conseils
Hors ligne
Habituellement on met entre 10 et 50, sur des serveurs bien plus gros que le votre, sauf cas vraiment particuliers (infocentres)
Marc.
Hors ligne
Rebonjour,
Je me permets de faire remonter ce post pour vous dire que j'ai modifié le paramètrage mémoire du moteur PostgreSQL et que maintenant les tâches de maintenance se déroulent sans problème.
shared_buffers = 50000
work_mem = 10240
maintenance_work_mem = 262144
Merci pour votre aide.
Hors ligne
Ces paramètres sont standard. Ça devrait bien se passer…
Marc.
Hors ligne
Pages : 1
