[PostgreSQL] Est ce que la base a besoin de chauffer le matin ?
16 réponses
Etienne
Salut.
j'ai un drole de comportement dans ma base de données, lorsque j'execute
explain analyze UPDATE mail SET is_deleted = 't' WHERE idmail IN
(166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,166075,166076);
J'obtiens
Bitmap Heap Scan on mail (cost=59.64..115.10 rows=14 width=1402)
(actual time=0.106..0.279 rows=14 loops=1)
Recheck Cond: (idmail = ANY
('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,1660
75,166076}'::integer[]))
-> Bitmap Index Scan on mail_pkey (cost=0.00..59.64 rows=14
width=0) (actual time=0.050..0.050 rows=27 loops=1)
Index Cond: (idmail = ANY
('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,
166075,166076}'::integer[]))
Trigger for constraint mail_idfrom_fkey: time=0.130 calls=14
Trigger for constraint mail_idparent_fkey: time=0.050 calls=14
Total runtime: 5202.918 ms
5 secondes quand même !!!
si j'exécute plusieurs fois le même code j'obtiens a peu prêt le même
résultat !!!
Après plusieurs exécutions de la même requête (même en changeant les
idmail) j'obtiens
Bitmap Heap Scan on mail (cost=59.64..115.10 rows=14 width=1402)
(actual time=0.085..0.156 rows=14 loops=1)
Recheck Cond: (idmail = ANY
('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,1660
75,166076}'::integer[]))
-> Bitmap Index Scan on mail_pkey (cost=0.00..59.64 rows=14
width=0) (actual time=0.052..0.052 rows=19 loops=1)
Index Cond: (idmail = ANY
('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,
166075,166076}'::integer[]))
Trigger for constraint mail_idfrom_fkey: time=0.061 calls=14
Trigger for constraint mail_idparent_fkey: time=0.047 calls=14
Total runtime: 12.523 ms
12 ms!
Alors pourquoi le matin, il me faut 5 secondes pour exécuter LES
premières requêtes alors qu'ensuite tout s'accélère ?
Ca ne doit pas être une histoire de chargement de table en RAM sinon dès
la deuxième exécution ca devrait aller plus vite non ?
Y a t-il un manque de RAM sur mon serveur ?
Comment peut-on détecter ce genre de problème ?
Le Thu, 09 Dec 2010 09:56:32 +0100, Etienne écrivait :
Salut.
Bonjour,
j'ai un drole de comportement dans ma base de données, lorsque j'execute
explain analyze UPDATE mail SET is_deleted = 't' WHERE idmail IN (166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,166075,166076);
J'obtiens Bitmap Heap Scan on mail (costY.64..115.10 rows width02) (actual time=0.106..0.279 rows loops=1) Recheck Cond: (idmail = ANY ('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,1660 75,166076}'::integer[])) -> Bitmap Index Scan on mail_pkey (cost=0.00..59.64 rows width=0) (actual time=0.050..0.050 rows' loops=1) Index Cond: (idmail = ANY ('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074, 166075,166076}'::integer[])) Trigger for constraint mail_idfrom_fkey: time=0.130 calls Trigger for constraint mail_idparent_fkey: time=0.050 calls Total runtime: 5202.918 ms
5 secondes quand même !!! si j'exécute plusieurs fois le même code j'obtiens a peu prêt le même résultat !!!
Après plusieurs exécutions de la même requête (même en changeant les idmail) j'obtiens
Bitmap Heap Scan on mail (costY.64..115.10 rows width02) (actual time=0.085..0.156 rows loops=1) Recheck Cond: (idmail = ANY ('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,1660 75,166076}'::integer[])) -> Bitmap Index Scan on mail_pkey (cost=0.00..59.64 rows width=0) (actual time=0.052..0.052 rows loops=1) Index Cond: (idmail = ANY ('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074, 166075,166076}'::integer[])) Trigger for constraint mail_idfrom_fkey: time=0.061 calls Trigger for constraint mail_idparent_fkey: time=0.047 calls Total runtime: 12.523 ms
12 ms!
Alors pourquoi le matin, il me faut 5 secondes pour exécuter LES premières requêtes alors qu'ensuite tout s'accélère ?
Ca ne doit pas être une histoire de chargement de table en RAM sinon dès la deuxième exécution ca devrait aller plus vite non ? Y a t-il un manque de RAM sur mon serveur ? Comment peut-on détecter ce genre de problème ?
Quel système d'exploitation histoire de rigoler ? Quels paramètres ?
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 09 Dec 2010 09:56:32 +0100,
Etienne <etienne@tlk.fr> écrivait :
Salut.
Bonjour,
j'ai un drole de comportement dans ma base de données, lorsque j'execute
explain analyze UPDATE mail SET is_deleted = 't' WHERE idmail IN
(166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,166075,166076);
J'obtiens
Bitmap Heap Scan on mail (costY.64..115.10 rows width02)
(actual time=0.106..0.279 rows loops=1)
Recheck Cond: (idmail = ANY
('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,1660
75,166076}'::integer[]))
-> Bitmap Index Scan on mail_pkey (cost=0.00..59.64 rows
width=0) (actual time=0.050..0.050 rows' loops=1)
Index Cond: (idmail = ANY
('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,
166075,166076}'::integer[]))
Trigger for constraint mail_idfrom_fkey: time=0.130 calls
Trigger for constraint mail_idparent_fkey: time=0.050 calls
Total runtime: 5202.918 ms
5 secondes quand même !!!
si j'exécute plusieurs fois le même code j'obtiens a peu prêt le même
résultat !!!
Après plusieurs exécutions de la même requête (même en changeant les
idmail) j'obtiens
Bitmap Heap Scan on mail (costY.64..115.10 rows width02)
(actual time=0.085..0.156 rows loops=1)
Recheck Cond: (idmail = ANY
('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,1660
75,166076}'::integer[]))
-> Bitmap Index Scan on mail_pkey (cost=0.00..59.64 rows
width=0) (actual time=0.052..0.052 rows loops=1)
Index Cond: (idmail = ANY
('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,
166075,166076}'::integer[]))
Trigger for constraint mail_idfrom_fkey: time=0.061 calls
Trigger for constraint mail_idparent_fkey: time=0.047 calls
Total runtime: 12.523 ms
12 ms!
Alors pourquoi le matin, il me faut 5 secondes pour exécuter LES
premières requêtes alors qu'ensuite tout s'accélère ?
Ca ne doit pas être une histoire de chargement de table en RAM sinon dès
la deuxième exécution ca devrait aller plus vite non ?
Y a t-il un manque de RAM sur mon serveur ?
Comment peut-on détecter ce genre de problème ?
Quel système d'exploitation histoire de rigoler ? Quels paramètres ?
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Thu, 09 Dec 2010 09:56:32 +0100, Etienne écrivait :
Salut.
Bonjour,
j'ai un drole de comportement dans ma base de données, lorsque j'execute
explain analyze UPDATE mail SET is_deleted = 't' WHERE idmail IN (166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,166075,166076);
J'obtiens Bitmap Heap Scan on mail (costY.64..115.10 rows width02) (actual time=0.106..0.279 rows loops=1) Recheck Cond: (idmail = ANY ('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,1660 75,166076}'::integer[])) -> Bitmap Index Scan on mail_pkey (cost=0.00..59.64 rows width=0) (actual time=0.050..0.050 rows' loops=1) Index Cond: (idmail = ANY ('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074, 166075,166076}'::integer[])) Trigger for constraint mail_idfrom_fkey: time=0.130 calls Trigger for constraint mail_idparent_fkey: time=0.050 calls Total runtime: 5202.918 ms
5 secondes quand même !!! si j'exécute plusieurs fois le même code j'obtiens a peu prêt le même résultat !!!
Après plusieurs exécutions de la même requête (même en changeant les idmail) j'obtiens
Bitmap Heap Scan on mail (costY.64..115.10 rows width02) (actual time=0.085..0.156 rows loops=1) Recheck Cond: (idmail = ANY ('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074,1660 75,166076}'::integer[])) -> Bitmap Index Scan on mail_pkey (cost=0.00..59.64 rows width=0) (actual time=0.052..0.052 rows loops=1) Index Cond: (idmail = ANY ('{166060,166062,166064,166066,166067,166068,166069,166070,166071,166072,166073,166074, 166075,166076}'::integer[])) Trigger for constraint mail_idfrom_fkey: time=0.061 calls Trigger for constraint mail_idparent_fkey: time=0.047 calls Total runtime: 12.523 ms
12 ms!
Alors pourquoi le matin, il me faut 5 secondes pour exécuter LES premières requêtes alors qu'ensuite tout s'accélère ?
Ca ne doit pas être une histoire de chargement de table en RAM sinon dès la deuxième exécution ca devrait aller plus vite non ? Y a t-il un manque de RAM sur mon serveur ? Comment peut-on détecter ce genre de problème ?
Quel système d'exploitation histoire de rigoler ? Quels paramètres ?
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Etienne
Le 09/12/2010 09:59, JKB a écrit :
Quel système d'exploitation histoire de rigoler ? Quels paramètres ?
JKB
Ca tourne sur une linux debian. Tu veux quoi comme paramètres ?
Je peux te déjà donner la config hardware Il s'agit d'un bi xeon quad core (3Ghz) 8 go de mémoire sont alloués à postgres 8.4.4 (qui tourne dans une machine virtuelle).
(Bon ca veut rien dire, les autres machines virtuelles pourraient utiliser toutes la charge mais ca ne semble pas être le cas).
Voila. tu veux d'autres infos ?
Etienne
Le 09/12/2010 09:59, JKB a écrit :
Quel système d'exploitation histoire de rigoler ? Quels paramètres ?
JKB
Ca tourne sur une linux debian.
Tu veux quoi comme paramètres ?
Je peux te déjà donner la config hardware
Il s'agit d'un bi xeon quad core (3Ghz)
8 go de mémoire sont alloués à postgres 8.4.4 (qui tourne dans une
machine virtuelle).
Quel système d'exploitation histoire de rigoler ? Quels paramètres ?
JKB
Ca tourne sur une linux debian. Tu veux quoi comme paramètres ?
Je peux te déjà donner la config hardware Il s'agit d'un bi xeon quad core (3Ghz) 8 go de mémoire sont alloués à postgres 8.4.4 (qui tourne dans une machine virtuelle).
(Bon ca veut rien dire, les autres machines virtuelles pourraient utiliser toutes la charge mais ca ne semble pas être le cas).
Voila. tu veux d'autres infos ?
Etienne
JKB
Le Thu, 09 Dec 2010 11:23:27 +0100, Etienne écrivait :
Le 09/12/2010 09:59, JKB a écrit :
Quel système d'exploitation histoire de rigoler ? Quels paramètres ?
JKB
Ca tourne sur une linux debian. Tu veux quoi comme paramètres ?
Les paramètres de configuration de la mémoire partagée Posix (shmem et les autres).
Je peux te déjà donner la config hardware Il s'agit d'un bi xeon quad core (3Ghz) 8 go de mémoire sont alloués à postgres 8.4.4 (qui tourne dans une machine virtuelle).
(Bon ca veut rien dire, les autres machines virtuelles pourraient utiliser toutes la charge mais ca ne semble pas être le cas).
Voila. tu veux d'autres infos ?
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et après les requêtes, ce qu'on peut trouver dans /etc/postgresql/8.4/main/postgresql.conf...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 09 Dec 2010 11:23:27 +0100,
Etienne <etienne@tlk.fr> écrivait :
Le 09/12/2010 09:59, JKB a écrit :
Quel système d'exploitation histoire de rigoler ? Quels paramètres ?
JKB
Ca tourne sur une linux debian.
Tu veux quoi comme paramètres ?
Les paramètres de configuration de la mémoire partagée Posix (shmem
et les autres).
Je peux te déjà donner la config hardware
Il s'agit d'un bi xeon quad core (3Ghz)
8 go de mémoire sont alloués à postgres 8.4.4 (qui tourne dans une
machine virtuelle).
(Bon ca veut rien dire, les autres machines virtuelles pourraient
utiliser toutes la charge mais ca ne semble pas être le cas).
Voila.
tu veux d'autres infos ?
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et
après les requêtes, ce qu'on peut trouver dans
/etc/postgresql/8.4/main/postgresql.conf...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Thu, 09 Dec 2010 11:23:27 +0100, Etienne écrivait :
Le 09/12/2010 09:59, JKB a écrit :
Quel système d'exploitation histoire de rigoler ? Quels paramètres ?
JKB
Ca tourne sur une linux debian. Tu veux quoi comme paramètres ?
Les paramètres de configuration de la mémoire partagée Posix (shmem et les autres).
Je peux te déjà donner la config hardware Il s'agit d'un bi xeon quad core (3Ghz) 8 go de mémoire sont alloués à postgres 8.4.4 (qui tourne dans une machine virtuelle).
(Bon ca veut rien dire, les autres machines virtuelles pourraient utiliser toutes la charge mais ca ne semble pas être le cas).
Voila. tu veux d'autres infos ?
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et après les requêtes, ce qu'on peut trouver dans /etc/postgresql/8.4/main/postgresql.conf...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Etienne
Le 09/12/2010 11:26, JKB a écrit :
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et après les requêtes, ce qu'on peut trouver dans /etc/postgresql/8.4/main/postgresql.conf...
Pour la taille de buffer, je ne sais pas comment on fait pour l'obtenir. sinon concernant la conf, il n'y a pas grand chose à dire.
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et
après les requêtes, ce qu'on peut trouver dans
/etc/postgresql/8.4/main/postgresql.conf...
Pour la taille de buffer, je ne sais pas comment on fait pour l'obtenir.
sinon concernant la conf, il n'y a pas grand chose à dire.
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et après les requêtes, ce qu'on peut trouver dans /etc/postgresql/8.4/main/postgresql.conf...
Pour la taille de buffer, je ne sais pas comment on fait pour l'obtenir. sinon concernant la conf, il n'y a pas grand chose à dire.
Le Thu, 09 Dec 2010 16:46:34 +0100, Etienne écrivait :
Le 09/12/2010 11:26, JKB a écrit :
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et après les requêtes, ce qu'on peut trouver dans /etc/postgresql/8.4/main/postgresql.conf...
Pour la taille de buffer, je ne sais pas comment on fait pour l'obtenir. sinon concernant la conf, il n'y a pas grand chose à dire.
Je n'ai pas toutes les informations demandées. L'algorithme linuxien de gestion du cache est assez particulier.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 09 Dec 2010 16:46:34 +0100,
Etienne <etienne@tlk.fr> écrivait :
Le 09/12/2010 11:26, JKB a écrit :
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et
après les requêtes, ce qu'on peut trouver dans
/etc/postgresql/8.4/main/postgresql.conf...
Pour la taille de buffer, je ne sais pas comment on fait pour l'obtenir.
sinon concernant la conf, il n'y a pas grand chose à dire.
Le Thu, 09 Dec 2010 16:46:34 +0100, Etienne écrivait :
Le 09/12/2010 11:26, JKB a écrit :
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et après les requêtes, ce qu'on peut trouver dans /etc/postgresql/8.4/main/postgresql.conf...
Pour la taille de buffer, je ne sais pas comment on fait pour l'obtenir. sinon concernant la conf, il n'y a pas grand chose à dire.
Je n'ai pas toutes les informations demandées. L'algorithme linuxien de gestion du cache est assez particulier.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Sebastien Lardiere
On 12/09/2010 04:46 PM, Etienne wrote:
Le 09/12/2010 11:26, JKB a écrit :
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et après les requêtes, ce qu'on peut trouver dans /etc/postgresql/8.4/main/postgresql.conf...
Pour la taille de buffer, je ne sais pas comment on fait pour l'obtenir. sinon concernant la conf, il n'y a pas grand chose à dire.
Vu la quantité de données manipulés, les paramétrages mémoire paraissent largement suffisant, mais ça ne dit rien sur l'activité que peut avoir la base en parallèle, ni sur sa taille totale.
Ensuite l'explain plan ne montre pas ou est consommé le temps ? N'en manquerait-il pas un morceau ?
Est-ce qu'il y a des taches de maintenance qui fonctionnent la nuit ? backup, vacuum ?
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est loin, avec les réglages ci-dessus ? comment les utilisez vous ?
-- Sébastien
On 12/09/2010 04:46 PM, Etienne wrote:
Le 09/12/2010 11:26, JKB a écrit :
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et
après les requêtes, ce qu'on peut trouver dans
/etc/postgresql/8.4/main/postgresql.conf...
Pour la taille de buffer, je ne sais pas comment on fait pour l'obtenir.
sinon concernant la conf, il n'y a pas grand chose à dire.
Vu la quantité de données manipulés, les paramétrages mémoire paraissent
largement suffisant, mais ça ne dit rien sur l'activité que peut avoir
la base en parallèle, ni sur sa taille totale.
Ensuite l'explain plan ne montre pas ou est consommé le temps ? N'en
manquerait-il pas un morceau ?
Est-ce qu'il y a des taches de maintenance qui fonctionnent la nuit ?
backup, vacuum ?
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est
loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Ouaips, la taille de 'buffers' et de la mémoire 'cached' avant et après les requêtes, ce qu'on peut trouver dans /etc/postgresql/8.4/main/postgresql.conf...
Pour la taille de buffer, je ne sais pas comment on fait pour l'obtenir. sinon concernant la conf, il n'y a pas grand chose à dire.
Vu la quantité de données manipulés, les paramétrages mémoire paraissent largement suffisant, mais ça ne dit rien sur l'activité que peut avoir la base en parallèle, ni sur sa taille totale.
Ensuite l'explain plan ne montre pas ou est consommé le temps ? N'en manquerait-il pas un morceau ?
Est-ce qu'il y a des taches de maintenance qui fonctionnent la nuit ? backup, vacuum ?
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est loin, avec les réglages ci-dessus ? comment les utilisez vous ?
-- Sébastien
Etienne
Le 13/12/2010 09:09, Sebastien Lardiere a écrit :
Salut,
Vu la quantité de données manipulés, les paramétrages mémoire paraissent largement suffisant, mais ça ne dit rien sur l'activité que peut avoir la base en parallèle, ni sur sa taille totale.
Bon le dump de la base fait 4Go...
Ensuite l'explain plan ne montre pas ou est consommé le temps ? N'en manquerait-il pas un morceau ?
Ben non j'ai tout mis. Peut être que je temps est pris par l'écriture sur disque (ce qui me semblerai assez étrange).
Est-ce qu'il y a des taches de maintenance qui fonctionnent la nuit ? backup, vacuum ?
Hum. Oui. En plus il s'agit de postresql 8.4 donc il y un auto vaccum.
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Heu en fait il s'agit d'une machine virtuelle qui dispose de 8Go. Sur cette machine virtuelle il n'y a que postgres qui tourne. (par contre il y a plusieurs bases).
Etienne
Le 13/12/2010 09:09, Sebastien Lardiere a écrit :
Salut,
Vu la quantité de données manipulés, les paramétrages mémoire paraissent
largement suffisant, mais ça ne dit rien sur l'activité que peut avoir
la base en parallèle, ni sur sa taille totale.
Bon le dump de la base fait 4Go...
Ensuite l'explain plan ne montre pas ou est consommé le temps ? N'en
manquerait-il pas un morceau ?
Ben non j'ai tout mis.
Peut être que je temps est pris par l'écriture sur disque (ce qui me
semblerai assez étrange).
Est-ce qu'il y a des taches de maintenance qui fonctionnent la nuit ?
backup, vacuum ?
Hum.
Oui.
En plus il s'agit de postresql 8.4 donc il y un auto vaccum.
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est
loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Heu en fait il s'agit d'une machine virtuelle qui dispose de 8Go.
Sur cette machine virtuelle il n'y a que postgres qui tourne.
(par contre il y a plusieurs bases).
Vu la quantité de données manipulés, les paramétrages mémoire paraissent largement suffisant, mais ça ne dit rien sur l'activité que peut avoir la base en parallèle, ni sur sa taille totale.
Bon le dump de la base fait 4Go...
Ensuite l'explain plan ne montre pas ou est consommé le temps ? N'en manquerait-il pas un morceau ?
Ben non j'ai tout mis. Peut être que je temps est pris par l'écriture sur disque (ce qui me semblerai assez étrange).
Est-ce qu'il y a des taches de maintenance qui fonctionnent la nuit ? backup, vacuum ?
Hum. Oui. En plus il s'agit de postresql 8.4 donc il y un auto vaccum.
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Heu en fait il s'agit d'une machine virtuelle qui dispose de 8Go. Sur cette machine virtuelle il n'y a que postgres qui tourne. (par contre il y a plusieurs bases).
Etienne
Sebastien Lardiere
On 12/20/2010 10:25 AM, Etienne wrote:
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Heu en fait il s'agit d'une machine virtuelle qui dispose de 8Go. Sur cette machine virtuelle il n'y a que postgres qui tourne. (par contre il y a plusieurs bases).
Ok, mais les reglages cités, venant de postgresql.conf ne refletent pas ça :
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est
loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Heu en fait il s'agit d'une machine virtuelle qui dispose de 8Go.
Sur cette machine virtuelle il n'y a que postgres qui tourne.
(par contre il y a plusieurs bases).
Ok, mais les reglages cités, venant de postgresql.conf ne refletent pas
ça :
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Heu en fait il s'agit d'une machine virtuelle qui dispose de 8Go. Sur cette machine virtuelle il n'y a que postgres qui tourne. (par contre il y a plusieurs bases).
Ok, mais les reglages cités, venant de postgresql.conf ne refletent pas ça :
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Heu en fait il s'agit d'une machine virtuelle qui dispose de 8Go. Sur cette machine virtuelle il n'y a que postgres qui tourne. (par contre il y a plusieurs bases).
Ok, mais les reglages cités, venant de postgresql.conf ne refletent pas ça :
Ah bon, faut que je mette encore plus dans le shmmax ??? comment calculer ces paramètres en fonction de la configuration ?
Etienne
Le 22/12/2010 11:34, Sebastien Lardiere a écrit :
On 12/20/2010 10:25 AM, Etienne wrote:
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est
loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Heu en fait il s'agit d'une machine virtuelle qui dispose de 8Go.
Sur cette machine virtuelle il n'y a que postgres qui tourne.
(par contre il y a plusieurs bases).
Ok, mais les reglages cités, venant de postgresql.conf ne refletent pas
ça :
Juste une remarque, vous parlez de 8GB de RAM disponible, mais on en est loin, avec les réglages ci-dessus ? comment les utilisez vous ?
Heu en fait il s'agit d'une machine virtuelle qui dispose de 8Go. Sur cette machine virtuelle il n'y a que postgres qui tourne. (par contre il y a plusieurs bases).
Ok, mais les reglages cités, venant de postgresql.conf ne refletent pas ça :
Ah bon, faut que je mette encore plus dans le shmmax ??? comment calculer ces paramètres en fonction de la configuration ?
le parametre kernel shmmax est une limite max.
Ce qui compte, c'est les parametres dans le fichier de configuration postgresql.conf
Tu disposes de 8GB, et tu utilises 128MB de mémoire partagée ( sur les 256MB autorisés ), et tu déclares 1GB de cache systeme utilisable.
Il y a d'autres parametres qui utilisent de la mémoire dans la conf ( work_mem, maintenance_work_mem ), mais tu peux augmenter ces reglages, par exemple :
shared_buffers = 1GB ( apres avoir monter la limite kernel shmmax ) effective_cache_size = 4GB
work_mem = 4MB ( * max_connections pour connaitre la limite max )
potentiellement, tu utiliseras mieux la mémoire de la VM.
Ah bon, faut que je mette encore plus dans le shmmax ???
comment calculer ces paramètres en fonction de la configuration ?
le parametre kernel shmmax est une limite max.
Ce qui compte, c'est les parametres dans le fichier de configuration
postgresql.conf
Tu disposes de 8GB, et tu utilises 128MB de mémoire partagée ( sur les
256MB autorisés ), et tu déclares 1GB de cache systeme utilisable.
Il y a d'autres parametres qui utilisent de la mémoire dans la conf (
work_mem, maintenance_work_mem ), mais tu peux augmenter ces reglages,
par exemple :
shared_buffers = 1GB ( apres avoir monter la limite kernel shmmax )
effective_cache_size = 4GB
work_mem = 4MB ( * max_connections pour connaitre la limite max )
potentiellement, tu utiliseras mieux la mémoire de la VM.
Ah bon, faut que je mette encore plus dans le shmmax ??? comment calculer ces paramètres en fonction de la configuration ?
le parametre kernel shmmax est une limite max.
Ce qui compte, c'est les parametres dans le fichier de configuration postgresql.conf
Tu disposes de 8GB, et tu utilises 128MB de mémoire partagée ( sur les 256MB autorisés ), et tu déclares 1GB de cache systeme utilisable.
Il y a d'autres parametres qui utilisent de la mémoire dans la conf ( work_mem, maintenance_work_mem ), mais tu peux augmenter ces reglages, par exemple :
shared_buffers = 1GB ( apres avoir monter la limite kernel shmmax ) effective_cache_size = 4GB
work_mem = 4MB ( * max_connections pour connaitre la limite max )
potentiellement, tu utiliseras mieux la mémoire de la VM.
