Vous n'êtes pas identifié(e).
Pages : 1
Merci Marc pour les liens, je me penche sur le problème du pool du connexion.
J'ai réalisé un test ce matin :
J'ai positionné dans postgresql.conf 5000 shared_buffers et 1 max_connections. Pmap m'indique alors ~40Mo de mémoire shared (donc chargé au démarrage, ce qui correspond a peu près à 5000 * 8k)
mapped: 146316K writeable/private: 1020K shared: 41864K
Lorsque je positionne à présent 2500 max_connections, pmap indique alors
mapped: 194380K writeable/private: 1020K shared: 89928K
Si je fait une bête division, j'obtiens environ 20k par connexion déclaré.
Mes questions sont les suivantes :
Quels paramètres Postgres rentrent en ligne de compte pour calculer la consommation par connexion?
Cette mémoire est elle bien occupé par postgres dans le système (normalement oui d'après ce que j'ai compris des explications)?
A plus tard,
Sébastien
Merci à vous deux pour vos réponses,
Gleu => J'ai fait un mélange entre max_connections et shared_buffers, c'est bien de shared_buffers dont je voulais parler.
shared_buffers, wal_buffers et quelques autres sont alloués au démarrage (en fait, tout ce qui est mémoire partagée). Ensuite chaque connexion va utiliser un peu de mémoire (notamment work_mem une à plusieurs fois et maintenance_work_mem.
Je vais tester vos indications quant à l'allocation de la mémoire pour controler la quantité de mémoire allouée au démarrage, sans connexion établie vers une base.
De plus vous indiquez :
Il n'y a pas de lien entre max_connections et shared_buffers.
Le lien que je vois est que shared_buffers doit être égal à 2*max_connections. Mais si j'ai bien compris, shared_buffers doit être au moins égal à 2*max_connections. Plus il y a de shared_buffers, mieux c'est, dans la limite des capacités du serveur.
Marc => Question intéressante, mais réponse complexe en effet...
J'avoue que le gestion de la mémoire pour Linux est encore très flou pour moi, avez vous un lien permettant de comprendre le fonctionnement de la mémoire sous linux (bref, une bonne vulgarisation)?
Vous indiquez que pour plus de 1000 il vaut mieux utilisé pgpool ou pgbouncer. Toutefois un point n'est pas clair encore. Pgpool ou pgbouncer permet, si j'ai bien compris, de garder un pool de connexions ouvert vers une base pour améliorer les performances (évite d'ouvrir et de fermer les connexions). Toutefois, dans le cas d'une appli ou on a une connexion ouverte vers la base par utilisateur et pour laquelle on veut garantir un accès vers la base, comment gérer 2500 utilisateurs connectés simultanément sur l'appli (donc en théorie autant de connexion vers la base)? Nous sommes bien obligé d'avoir 2500 connexions (max_connections) déclaré sur postgres, non?
Nous utilisons déjà un pool de connexions (avec c3p0 via hibernate), pgpool ou pgbouncer seraient-ils utilent dans ce cas de figure. Je ne pense pas mais je voudrais votre avis à ce sujet.
Le document indiqué en lien est très intéressant, je n'ai pas pu utiliser la contrib indiquée car j'utilise encore Postgre 8.0 et je n'ai pas trouvé la contrib pour cette version. Quel gain peut on attendre à passer vers postgres 8.4?
A vous lire, Sébastien
Merci Gleu pour la réponse,
J'admet avoir encore un peu de mal à m'y retrouver pour calculer la consommation mémoire :
la commande PS me retourne les valeurs suivantes :
postgres 3431 0.0 0.1 82544 18600 ? S 2009 11:52 /usr/local/pgsql/bin/postmaster
Dois-je comprendre que le processus global consomme 82Mo environ?
De plus à chaque connexion vers la base de données j'ai les valeurs suivantes :
postgres 32633 0.0 0.0 83280 2728 ? S 2009 0:00 postgres: postgres Demo 127.0.0.1(39206) idle
postgres 32682 0.0 0.0 83280 2732 ? S 2009 0:00 postgres: postgres Demo 127.0.0.1(53022) idle
postgres 32683 0.0 0.0 83280 2708 ? S 2009 0:00 postgres: postgres Demo 127.0.0.1(42895) idle
Est-ce que je dois comprendre que chaque processus consomme 83Mo?
Le doc fourni en lien est très intéressant, toutefois je ne comprends pas très bien dans la conclusion le point suivant :
vos transactions sont particulièrement longues ou vous avez de nombreux clients connectés en même temps ? Pensez à accroître wal_buffers ;
En effet, le fichier postgres.conf annoté "http://docs.postgresql.fr/annotated_pos … #id2473539" indique pour le paramètre wal_buffers :
L'accroissement de ce paramètre n'a que peu d'influence, même dans le cas de systèmes OLTP (On-Line Transaction Processing) chargés. Dans le cas de transactions conséquentes, on peut accroître ce paramètre par sécurité (de 16 à 64), mais il est préférable de se concentrer sur checkpoint_segments.
Qu'appelle ton de nombreux clients connectés (10,1000,10000)?
Encore un point, sur un serveur non dédié à postgres, quelle est la taille max_buffers qu'on peut utilisé. Je crois que pour un serveur dédié on indique 1/4 de la mémoire du serveur.
Merci d'avance pour votre aide,
Sébastien
Bonjour à tous,
J'utilise une base Postgres depuis un certain temps maintenant, mais je suis bien embêté pour dimensionner la mémoire d'un serveur sur lequel est installé Postgres.
Je m'explique :
Le nombre d'utilisateurs simultanés qui peuvent se connecter à l'application est connu. De là, je peux facilement connaitre le max_connexion nécessaire ainsi que la valeur shared_buffer.
Toutefois je ne sais pas si la mémoire est allouée au démarrage de Postgres ou bien si chaque connexion à la base viendra utiliser un peu de mémoire jusqu'à la limite permise.
Bref j'aimerai savoir comment déterminer :
- la mémoire nécessaire au noyau Postgres
- la mémoire utilisé par une connexion
Je ne suis pas un expert système, et je me bats un peu avec les outils type top, pmap et free pour essayer de comprendre quelque chose à la consommation mémoire...
Merci d'avance pour toute aide,
Sébastien
Pages : 1