Vous n'êtes pas identifié(e).
Pages : 1
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
Hors ligne
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.
Il n'y a pas de lien entre max_connections et shared_buffers.
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.
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.
Vous aurez plus de détails sur http://www.dalibo.org/glmf107_gestion_m … postgresql .
Guillaume.
Hors ligne
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
Hors ligne
Les questions sont intéressantes mais n'amènent pas de réponse simple : la gestion de la mémoire sous Unix est un sujet vaste et assez compliqué, les processus ayant tendance à beaucoup partager leur mémoire. Par exemple, vos processus à chacun 83 Mo ne consomment chacun qu'une très faible partie de ces 83 Mo : la plupart des pages mémoires des processus seront partagées.
La mémoire partagée entre les processus est principalement de 3 sortes (l'explication est rapide, si le sujet vous intéresse, je vous conseille de le creuser) :
- la 'shared memory', qui est celle que vous avez déclarée dans la configuration Postgres. Il s'agit de mémoire explicitement déclarée comme partagée entre les processus, et accessible en lecture/écriture par tous les processus participant à Postgres
- de la mémoire mappée sur les librairies dynamiques : si votre programme utilise des libraires dynamiques (comme postgres le fait évidemment), ces librairies sont mappées dans l'espace mémoire du processus. Mais elles ne sont pas chargées autant de fois que de programmes l'utilisant sur le système
- de la mémoire 'copy on write' : il s'agit de pages mémoires que les processus possèdent, voient comme étant la leur, mais sera dupliquée s'ils décidaient d'écrire dedans. Ces pages sont le résultat de l'appel système fork utilisé pour créer de nouveaux processus sous Unix (http://fr.wikipedia.org/wiki/Fork). Comme les nouveaux processus sont obtenus par clonage, il est plus performant, plutôt que de recopier la mémoire du processus initial, de faire pointer les pages mémoires du père et du fils vers les mêmes pages mémoires, quitte à devoir dupliquer celles devant changer au moment de la modification (copy on write).
La commande pmap -d permet sous linux d'avoir une vue un peu plus précise de ce qu'est la mémoire d'un processus. Par exemple sur un de mes processus postgres :
> pmap -d 32725
32725: postgres: stats_internet stats_internet 89.133.2.222(35397) idle
Address Kbytes Mode Offset Device Mapping
00002b7005131000 116 r-x-- 0000000000000000 008:00001 ld-2.10.2.so
00002b700514e000 12 rw--- 00002b700514e000 000:00000 [ anon ]
00002b7005151000 1792 r---- 0000000000000000 0fd:00002 locale-archive
00002b700534d000 4 r---- 000000000001c000 008:00001 ld-2.10.2.so
00002b700534e000 4 rw--- 000000000001d000 008:00001 ld-2.10.2.so
00002b700534f000 1348 r-x-- 0000000000000000 0fd:00002 libxml2.so.2.7.6
00002b70054a0000 2044 ----- 0000000000151000 0fd:00002 libxml2.so.2.7.6
00002b700569f000 40 rw--- 0000000000150000 0fd:00002 libxml2.so.2.7.6
00002b70056a9000 4 rw--- 00002b70056a9000 000:00000 [ anon ]
00002b70056aa000 44 r-x-- 0000000000000000 008:00001 libpam.so.0.81.12
00002b70056b5000 2044 ----- 000000000000b000 008:00001 libpam.so.0.81.12
00002b70058b4000 4 rw--- 000000000000a000 008:00001 libpam.so.0.81.12
00002b70058b5000 300 r-x-- 0000000000000000 0fd:00002 libssl.so.0.9.8
00002b7005900000 2048 ----- 000000000004b000 0fd:00002 libssl.so.0.9.8
00002b7005b00000 28 rw--- 000000000004b000 0fd:00002 libssl.so.0.9.8
00002b7005b07000 1484 r-x-- 0000000000000000 0fd:00002 libcrypto.so.0.9.8
00002b7005c7a000 2048 ----- 0000000000173000 0fd:00002 libcrypto.so.0.9.8
00002b7005e7a000 160 rw--- 0000000000173000 0fd:00002 libcrypto.so.0.9.8
00002b7005ea2000 16 rw--- 00002b7005ea2000 000:00000 [ anon ]
00002b7005ea6000 716 r-x-- 0000000000000000 0fd:00002 libkrb5.so.3.3
00002b7005f59000 2048 ----- 00000000000b3000 0fd:00002 libkrb5.so.3.3
00002b7006159000 40 rw--- 00000000000b3000 0fd:00002 libkrb5.so.3.3
00002b7006163000 12 r-x-- 0000000000000000 008:00001 libcom_err.so.2.1
00002b7006166000 2044 ----- 0000000000003000 008:00001 libcom_err.so.2.1
00002b7006365000 4 rw--- 0000000000002000 008:00001 libcom_err.so.2.1
00002b7006366000 180 r-x-- 0000000000000000 0fd:00002 libgssapi_krb5.so.2.2
00002b7006393000 2044 ----- 000000000002d000 0fd:00002 libgssapi_krb5.so.2.2
00002b7006592000 8 rw--- 000000000002c000 0fd:00002 libgssapi_krb5.so.2.2
00002b7006594000 4 rw--- 00002b7006594000 000:00000 [ anon ]
00002b7006595000 8 r-x-- 0000000000000000 008:00001 libdl-2.10.2.so
00002b7006597000 2048 ----- 0000000000002000 008:00001 libdl-2.10.2.so
00002b7006797000 4 r---- 0000000000002000 008:00001 libdl-2.10.2.so
00002b7006798000 4 rw--- 0000000000003000 008:00001 libdl-2.10.2.so
00002b7006799000 516 r-x-- 0000000000000000 008:00001 libm-2.10.2.so
00002b700681a000 2044 ----- 0000000000081000 008:00001 libm-2.10.2.so
00002b7006a19000 4 r---- 0000000000080000 008:00001 libm-2.10.2.so
00002b7006a1a000 4 rw--- 0000000000081000 008:00001 libm-2.10.2.so
00002b7006a1b000 280 r-x-- 0000000000000000 0fd:00002 libldap_r-2.4.so.2.4.1
00002b7006a61000 2048 ----- 0000000000046000 0fd:00002 libldap_r-2.4.so.2.4.1
00002b7006c61000 12 rw--- 0000000000046000 0fd:00002 libldap_r-2.4.so.2.4.1
00002b7006c64000 12 rw--- 00002b7006c64000 000:00000 [ anon ]
00002b7006c67000 1320 r-x-- 0000000000000000 008:00001 libc-2.10.2.so
00002b7006db1000 2048 ----- 000000000014a000 008:00001 libc-2.10.2.so
00002b7006fb1000 16 r---- 000000000014a000 008:00001 libc-2.10.2.so
00002b7006fb5000 4 rw--- 000000000014e000 008:00001 libc-2.10.2.so
00002b7006fb6000 20 rw--- 00002b7006fb6000 000:00000 [ anon ]
00002b7006fbb000 92 r-x-- 0000000000000000 0fd:00002 libz.so.1.2.3.3
00002b7006fd2000 2044 ----- 0000000000017000 0fd:00002 libz.so.1.2.3.3
00002b70071d1000 4 rw--- 0000000000016000 0fd:00002 libz.so.1.2.3.3
00002b70071d2000 164 r-x-- 0000000000000000 0fd:00002 libk5crypto.so.3.1
00002b70071fb000 2048 ----- 0000000000029000 0fd:00002 libk5crypto.so.3.1
00002b70073fb000 8 rw--- 0000000000029000 0fd:00002 libk5crypto.so.3.1
00002b70073fd000 4 rw--- 00002b70073fd000 000:00000 [ anon ]
00002b70073fe000 28 r-x-- 0000000000000000 0fd:00002 libkrb5support.so.0.1
00002b7007405000 2048 ----- 0000000000007000 0fd:00002 libkrb5support.so.0.1
00002b7007605000 4 rw--- 0000000000007000 0fd:00002 libkrb5support.so.0.1
00002b7007606000 8 r-x-- 0000000000000000 008:00001 libkeyutils-1.2.so
00002b7007608000 2044 ----- 0000000000002000 008:00001 libkeyutils-1.2.so
00002b7007807000 4 rw--- 0000000000001000 008:00001 libkeyutils-1.2.so
00002b7007808000 76 r-x-- 0000000000000000 008:00001 libresolv-2.10.2.so
00002b700781b000 2044 ----- 0000000000013000 008:00001 libresolv-2.10.2.so
00002b7007a1a000 4 r---- 0000000000012000 008:00001 libresolv-2.10.2.so
00002b7007a1b000 4 rw--- 0000000000013000 008:00001 libresolv-2.10.2.so
00002b7007a1c000 12 rw--- 00002b7007a1c000 000:00000 [ anon ]
00002b7007a1f000 88 r-x-- 0000000000000000 008:00001 libpthread-2.10.2.so
00002b7007a35000 2048 ----- 0000000000016000 008:00001 libpthread-2.10.2.so
00002b7007c35000 4 r---- 0000000000016000 008:00001 libpthread-2.10.2.so
00002b7007c36000 4 rw--- 0000000000017000 008:00001 libpthread-2.10.2.so
00002b7007c37000 16 rw--- 00002b7007c37000 000:00000 [ anon ]
00002b7007c3b000 56 r-x-- 0000000000000000 0fd:00002 liblber-2.4.so.2.4.1
00002b7007c49000 2048 ----- 000000000000e000 0fd:00002 liblber-2.4.so.2.4.1
00002b7007e49000 4 rw--- 000000000000e000 0fd:00002 liblber-2.4.so.2.4.1
00002b7007e4a000 100 r-x-- 0000000000000000 0fd:00002 libsasl2.so.2.0.22
00002b7007e63000 2048 ----- 0000000000019000 0fd:00002 libsasl2.so.2.0.22
00002b7008063000 4 rw--- 0000000000019000 0fd:00002 libsasl2.so.2.0.22
00002b7008064000 4 rw--- 00002b7008064000 000:00000 [ anon ]
00002b7008065000 668 r-x-- 0000000000000000 0fd:00002 libgnutls.so.26.11.6
00002b700810c000 2048 ----- 00000000000a7000 0fd:00002 libgnutls.so.26.11.6
00002b700830c000 44 rw--- 00000000000a7000 0fd:00002 libgnutls.so.26.11.6
00002b7008317000 64 r-x-- 0000000000000000 0fd:00002 libtasn1.so.3.1.2
00002b7008327000 2044 ----- 0000000000010000 0fd:00002 libtasn1.so.3.1.2
00002b7008526000 4 rw--- 000000000000f000 0fd:00002 libtasn1.so.3.1.2
00002b7008527000 4 rw--- 00002b7008527000 000:00000 [ anon ]
00002b7008528000 460 r-x-- 0000000000000000 0fd:00002 libgcrypt.so.11.5.2
00002b700859b000 2044 ----- 0000000000073000 0fd:00002 libgcrypt.so.11.5.2
00002b700879a000 16 rw--- 0000000000072000 0fd:00002 libgcrypt.so.11.5.2
00002b700879e000 12 r-x-- 0000000000000000 0fd:00002 libgpg-error.so.0.4.0
00002b70087a1000 2044 ----- 0000000000003000 0fd:00002 libgpg-error.so.0.4.0
00002b70089a0000 4 rw--- 0000000000002000 0fd:00002 libgpg-error.so.0.4.0
00002b70089a1000 12 rw--- 00002b70089a1000 000:00000 [ anon ]
00002b70089a4000 28 r-x-- 0000000000000000 008:00001 libnss_compat-2.10.2.so
00002b70089ab000 2044 ----- 0000000000007000 008:00001 libnss_compat-2.10.2.so
00002b7008baa000 4 r---- 0000000000006000 008:00001 libnss_compat-2.10.2.so
00002b7008bab000 4 rw--- 0000000000007000 008:00001 libnss_compat-2.10.2.so
00002b7008bac000 84 r-x-- 0000000000000000 008:00001 libnsl-2.10.2.so
00002b7008bc1000 2044 ----- 0000000000015000 008:00001 libnsl-2.10.2.so
00002b7008dc0000 4 r---- 0000000000014000 008:00001 libnsl-2.10.2.so
00002b7008dc1000 4 rw--- 0000000000015000 008:00001 libnsl-2.10.2.so
00002b7008dc2000 8 rw--- 00002b7008dc2000 000:00000 [ anon ]
00002b7008dc4000 40 r-x-- 0000000000000000 008:00001 libnss_nis-2.10.2.so
00002b7008dce000 2044 ----- 000000000000a000 008:00001 libnss_nis-2.10.2.so
00002b7008fcd000 4 r---- 0000000000009000 008:00001 libnss_nis-2.10.2.so
00002b7008fce000 4 rw--- 000000000000a000 008:00001 libnss_nis-2.10.2.so
00002b7008fcf000 44 r-x-- 0000000000000000 008:00001 libnss_files-2.10.2.so
00002b7008fda000 2044 ----- 000000000000b000 008:00001 libnss_files-2.10.2.so
00002b70091d9000 4 r---- 000000000000a000 008:00001 libnss_files-2.10.2.so
00002b70091da000 4 rw--- 000000000000b000 008:00001 libnss_files-2.10.2.so
00002b70091db000 16 r-x-- 0000000000000000 0fd:00002 pg_stat_statements.so
00002b70091df000 2044 ----- 0000000000004000 0fd:00002 pg_stat_statements.so
00002b70093de000 4 r---- 0000000000003000 0fd:00002 pg_stat_statements.so
00002b70093df000 4 rw--- 0000000000004000 0fd:00002 pg_stat_statements.so
00002b70093e0000 8 r-x-- 0000000000000000 0fd:00002 auto_explain.so
00002b70093e2000 2044 ----- 0000000000002000 0fd:00002 auto_explain.so
00002b70095e1000 4 r---- 0000000000001000 0fd:00002 auto_explain.so
00002b70095e2000 4 rw--- 0000000000002000 0fd:00002 auto_explain.so
00002b70095e3000 1127936 rw-s- 0000000000000000 000:00008 [ shmid=0xf0000 ]
00002b704e363000 516 rw--- 00002b704e363000 000:00000 [ anon ]
00002b704e3e5000 392 rw--- 00002b704e3e5000 000:00000 [ anon ]
00002b704e447000 160 r-x-- 0000000000000000 0fd:00002 plpgsql.so
00002b704e46f000 2044 ----- 0000000000028000 0fd:00002 plpgsql.so
00002b704e66e000 8 r---- 0000000000027000 0fd:00002 plpgsql.so
00002b704e670000 4 rw--- 0000000000029000 0fd:00002 plpgsql.so
00002b704e671000 516 rw--- 00002b704e671000 000:00000 [ anon ]
0000555555554000 4552 r-x-- 0000000000000000 0fd:00002 postgres
0000555555bc5000 108 r---- 0000000000471000 0fd:00002 postgres
0000555555be0000 52 rw--- 000000000048c000 0fd:00002 postgres
0000555555bed000 5896 rw--- 0000555555bed000 000:00000 [ anon ]
00007fffa594b000 184 rw--- 00007fffa594b000 000:00000 [ stack ]
ffffffffff600000 8192 ----- 0000000000000000 000:00000 [ anon ]
mapped: 1220664K writeable/private: 8128K shared: 1127936KOn a donc un processus ayant 1,2Go de RAM 'mappée', c'est à dire allouée, mais seulement 8Mo de mémoire 'privée'.
Pour ce qui est des questions au dessous, le WAL segment n'a en effet pas beaucoup d'importance, sauf dans des cas un peu extrèmes. Malgré tout, comme il ne s'agit pas de beaucoup de mémoir, j'ai tendance à le mettre à 4Mo dès le départ, histoire de ne plus avoir à me poser de question à son sujet.
Un dernier point, sur le 'nombreux clients connectés' : ça devient une très mauvaise idée d'avoir plus de 1000 clients connectés à une base, mieux vaut avoir recours au pooling avec pgpool ou pgbouncer bien avant (quelques dizaines à centaines de connexion, suivant le contexte et la machine).
Dernière modification par Marc Cousin (06/01/2010 11:39:56)
Marc.
Hors ligne
Pour le dernier point auquel Marc, me semble-t-il, n'a pas répondu, il ne s'agit pas de max_buffers, mais de shared_buffers. Et en effet, généralement, on y colle 1/4 de la RAM pour un serveur dédié. Évidemment, ce n'est qu'une valeur de départ, et il est conseillé de tester différentes valeurs.
Marc, excellent la commande pmap, je ne connaissais pas. Merci 
Guillaume.
Hors ligne
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
Hors ligne
Je ne connais pas de 'vulgarisation' sur le sujet. Il y a toujours cet article assez complet : http://www.linuxhq.com/guides/TLK/mm/memory.html , mais il est un peu ancien. Sinon il y a cet excellent livre : http://kernel.org/doc/gorman/pdf/understand.pdf, mais il fait 700 pages
Pour ce qui est du pooling. il est très improbable, malgré les 2500 utilisateurs, qu'ils veuillent simultanément exécuter des requêtes (ou des transactions). Le pooler s'occupera donc de redistribuer les sessions inactives (qui n'ont pas de transaction en cours) d'un utilisateur à l'autre. Mais vous avez raison, si vous avez c3p0 en amont, il est possible que ça fasse double usage. Cela dépend de si vous pensez réellement que vos serveurs vont monter 2500 connexions qui seront actives simultanément. De toutes façons, si c'est le cas, vous aurez de gros problèmes de performance, et ce quel que soit le SGBD : même avec Oracle vous devrez passer au pooling (les shared servers).
Par ailleurs, même si vous avez 2500 utilisateurs applicatifs, vus du côté de tomcat ou jboss, c3p0 ne montera pas 2500 sessions à la base. C'est son rôle de limiter le nombre de celles ci, afin de n'utiliser que le minimum de sessions permettant de répondre aux requêtes SIMULTANÉMENT exécutées (si je dis une bêtise là, merci à un spécialiste java de me contredire). De toutes façons, vous ne gagnerez pas en nombre de requêtes par seconde au dessus de quelques requêtes s'exécutant simultanément. Je pense donc que votre nombre de 2500 sessions est très surestimé.
Marc.
Hors ligne
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: 41864KLorsque je positionne à présent 2500 max_connections, pmap indique alors
mapped: 194380K writeable/private: 1020K shared: 89928KSi 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
Hors ligne
Si vous voulez connaître la taille de la mémoire partagée demandée par postgresql au démarrage du cluster, la commande ipcs -m vous l'indique.
La valeur de 20k me semble un peu élevée pour une session. Quand on augmente le max_connections, postgresql crée un tableau de structure PGPROC, de taille max_connections. La structure a l'air assez petite, loin des 20k.
De toutes façons, à moins d'avoir un serveur énorme, vous n'aurez pas souvent plus de 100 à 500 sessions sur un serveur, je pense que vous perdez votre temps à essayer de quantifier la quantité de mémoire partagée, quand vous pourriez vous retrouver avec 2000 tris simultanés si toutes vos sessions font des requêtes en même temps (on ne parle plus de 20k là, mais de plusieurs Mo par tri).
Si malgré tout vous voulez aller plus avant, je vous conseille de lire ce chapitre de la doc : http://docs.postgresql.fr/8.4/runtime-config.html
Marc.
Hors ligne
Pages : 1