[PostgreSQL] Est ce que la base a besoin de chauffer le matin ?

Le
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 (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 ?

Merci
Etienne
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #22902221
Le Thu, 09 Dec 2010 09:56:32 +0100,
Etienne
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 #22902741
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).

Il n'y a pas de charge ni de swap à priori.

Cpu(s): 2.8%us, 0.7%sy, 0.0%ni, 95.1%id, 1.2%wa, 0.0%hi, 0.0%si,
0.1%st
Mem: 8389108k total, 7688844k used, 700264k free, 74764k buffers
Swap: 0k total, 0k used, 0k free, 7211508k cached

(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 #22902731
Le Thu, 09 Dec 2010 11:23:27 +0100,
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 ?



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).



Beuhwa...

Il n'y a pas de charge ni de swap à priori.

Cpu(s): 2.8%us, 0.7%sy, 0.0%ni, 95.1%id, 1.2%wa, 0.0%hi, 0.0%si,
0.1%st
Mem: 8389108k total, 7688844k used, 700264k free, 74764k buffers
Swap: 0k total, 0k used, 0k free, 7211508k cached

(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 #22904281
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.

-config postgresql

shared_buffers = 128MB
effective_cache_size = 1024MB

- memoire partagée

shmmax = 268435456

voila.
Etienne
JKB
Le #22908381
Le Thu, 09 Dec 2010 16:46:34 +0100,
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.

-config postgresql

shared_buffers = 128MB
effective_cache_size = 1024MB

- memoire partagée

shmmax = 268435456



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
Le #22919501
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.

-config postgresql

shared_buffers = 128MB
effective_cache_size = 1024MB

- memoire partagée

shmmax = 268435456




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.

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 #22943701
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
Sebastien Lardiere
Le #22949751
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 :

-config postgresql

shared_buffers = 128MB
effective_cache_size = 1024MB

- memoire partagée

shmmax = 268435456




On est loin des 8GB, là

--
Sébastien
Etienne
Le #22950251
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 :

-config postgresql

shared_buffers = 128MB
effective_cache_size = 1024MB

- memoire partagée

shmmax = 268435456




On est loin des 8GB, là



Ah bon, faut que je mette encore plus dans le shmmax ???
comment calculer ces paramètres en fonction de la configuration ?

Etienne
Sebastien Lardiere
Le #22950801
On 12/22/2010 03:03 PM, Etienne wrote:

-config postgresql

shared_buffers = 128MB
effective_cache_size = 1024MB

- memoire partagée

shmmax = 268435456




On est loin des 8GB, là



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.

--
Sébastien
Publicité
Poster une réponse
Anonyme