[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 ?
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).
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Etienne
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Bonjour,
Le 20/12/2010 10:25, Etienne a écrit :
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).
en règle générale les machines virtuelles tuent les performances des SGBDR.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Etienne
A +
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
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).
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Etienne
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
helios
SQLpro a écrit :
Bonjour,
Le 20/12/2010 10:25, Etienne a écrit :
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).
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
si je dis ce que je penses de cet article Brouard vas encore être faché et vouloir faire un procés en diffamation sans savoir que cela aboutira encore par une non condamnation
Etienne
A +
SQLpro a écrit :
Bonjour,
Le 20/12/2010 10:25, Etienne a écrit :
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).
en règle générale les machines virtuelles tuent les performances des
SGBDR.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
si je dis ce que je penses de cet article Brouard vas encore être faché
et vouloir faire un procés en diffamation sans savoir que cela aboutira
encore par une non condamnation
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).
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
si je dis ce que je penses de cet article Brouard vas encore être faché et vouloir faire un procés en diffamation sans savoir que cela aboutira encore par une non condamnation
Etienne
A +
Etienne
Le 01/01/2011 09:52, SQLpro a écrit :
Bonjour,
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Je suis assez enclin à vous croire.
car les logs des requètes que j'execute sont les suivants
[ext_v2]0.0003049373626709:UPDATE mail SET is_deleted = 't' WHERE idmail = 171302; [ext_v2]0.00030899047851562:UPDATE mail SET is_deleted = 't' WHERE idmail = 171303; [ext_v2]0.021498203277588:UPDATE mail SET is_deleted = 't' WHERE idmail = 171304; [ext_v2]0.00056886672973633:UPDATE mail SET is_deleted = 't' WHERE idmail = 171305; [ext_v2]0.036141157150269:UPDATE mail SET is_deleted = 't' WHERE idmail = 171306; [ext_v2]0.00051093101501465:UPDATE mail SET is_deleted = 't' WHERE idmail = 171307; [ext_v2]0.00030684471130371:UPDATE mail SET is_deleted = 't' WHERE idmail = 171308; [ext_v2]0.00031399726867676:UPDATE mail SET is_deleted = 't' WHERE idmail = 171309; [ext_v2]2.276673078537:UPDATE mail SET is_deleted = 't' WHERE idmail = 171310; [ext_v2]0.00075697898864746:UPDATE mail SET is_deleted = 't' WHERE idmail = 171311; [ext_v2]0.00035309791564941:UPDATE mail SET is_deleted = 't' WHERE idmail = 171312; [ext_v2]0.00032401084899902:UPDATE mail SET is_deleted = 't' WHERE idmail = 171313; [ext_v2]0.015580892562866:UPDATE mail SET is_deleted = 't' WHERE idmail = 171314;
Une même requête (sauf évidement l'id qui change) exécutée dans une même transaction prends ici 10.000 fois plus de temps... c'est pas top normal d'après moi.
Surtout que si je ne m'abuse, vu que c'est dans une transaction, il ne doit pas y avoir d'écriture sur disque avant le commit non ?
Etienne
Etienne
Le 01/01/2011 09:52, SQLpro a écrit :
Bonjour,
en règle générale les machines virtuelles tuent les performances des SGBDR.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Je suis assez enclin à vous croire.
car les logs des requètes que j'execute sont les suivants
[ext_v2]0.0003049373626709:UPDATE mail SET is_deleted = 't' WHERE idmail
= 171302;
[ext_v2]0.00030899047851562:UPDATE mail SET is_deleted = 't' WHERE
idmail = 171303;
[ext_v2]0.021498203277588:UPDATE mail SET is_deleted = 't' WHERE idmail
= 171304;
[ext_v2]0.00056886672973633:UPDATE mail SET is_deleted = 't' WHERE
idmail = 171305;
[ext_v2]0.036141157150269:UPDATE mail SET is_deleted = 't' WHERE idmail
= 171306;
[ext_v2]0.00051093101501465:UPDATE mail SET is_deleted = 't' WHERE
idmail = 171307;
[ext_v2]0.00030684471130371:UPDATE mail SET is_deleted = 't' WHERE
idmail = 171308;
[ext_v2]0.00031399726867676:UPDATE mail SET is_deleted = 't' WHERE
idmail = 171309;
[ext_v2]2.276673078537:UPDATE mail SET is_deleted = 't' WHERE idmail =
171310;
[ext_v2]0.00075697898864746:UPDATE mail SET is_deleted = 't' WHERE
idmail = 171311;
[ext_v2]0.00035309791564941:UPDATE mail SET is_deleted = 't' WHERE
idmail = 171312;
[ext_v2]0.00032401084899902:UPDATE mail SET is_deleted = 't' WHERE
idmail = 171313;
[ext_v2]0.015580892562866:UPDATE mail SET is_deleted = 't' WHERE idmail
= 171314;
Une même requête (sauf évidement l'id qui change) exécutée dans une même
transaction prends ici 10.000 fois plus de temps... c'est pas top normal
d'après moi.
Surtout que si je ne m'abuse, vu que c'est dans une transaction, il ne
doit pas y avoir d'écriture sur disque avant le commit non ?
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Je suis assez enclin à vous croire.
car les logs des requètes que j'execute sont les suivants
[ext_v2]0.0003049373626709:UPDATE mail SET is_deleted = 't' WHERE idmail = 171302; [ext_v2]0.00030899047851562:UPDATE mail SET is_deleted = 't' WHERE idmail = 171303; [ext_v2]0.021498203277588:UPDATE mail SET is_deleted = 't' WHERE idmail = 171304; [ext_v2]0.00056886672973633:UPDATE mail SET is_deleted = 't' WHERE idmail = 171305; [ext_v2]0.036141157150269:UPDATE mail SET is_deleted = 't' WHERE idmail = 171306; [ext_v2]0.00051093101501465:UPDATE mail SET is_deleted = 't' WHERE idmail = 171307; [ext_v2]0.00030684471130371:UPDATE mail SET is_deleted = 't' WHERE idmail = 171308; [ext_v2]0.00031399726867676:UPDATE mail SET is_deleted = 't' WHERE idmail = 171309; [ext_v2]2.276673078537:UPDATE mail SET is_deleted = 't' WHERE idmail = 171310; [ext_v2]0.00075697898864746:UPDATE mail SET is_deleted = 't' WHERE idmail = 171311; [ext_v2]0.00035309791564941:UPDATE mail SET is_deleted = 't' WHERE idmail = 171312; [ext_v2]0.00032401084899902:UPDATE mail SET is_deleted = 't' WHERE idmail = 171313; [ext_v2]0.015580892562866:UPDATE mail SET is_deleted = 't' WHERE idmail = 171314;
Une même requête (sauf évidement l'id qui change) exécutée dans une même transaction prends ici 10.000 fois plus de temps... c'est pas top normal d'après moi.
Surtout que si je ne m'abuse, vu que c'est dans une transaction, il ne doit pas y avoir d'écriture sur disque avant le commit non ?
Etienne
Etienne
Etienne
Le 01/01/2011 09:52, SQLpro a écrit :
Bonjour,
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Bon tu avais raison...
Alors voila l'explication (enfin disons mon interprétation du problème). lorsque je supprime des mails (sur mon client mail) - j'exécute la suppression sur le serveur de mail - j'exécute la suppression sur postgresql
le serveur imap et postgresql tournent tous les deux dans 2 machines virtuelles séparées, mais... partage le même raid. (erreur !!!)
Donc lorsque j'exécute ma requêtes SQL, pas de chance, linux est en train de supprimer les mails (physiquement). Postgres, pour qui, il n'y a pas d'IO à ce moment décide lui aussi de flusher ses caches. Et boum... c'est le bouchon.
Donc le matin lorsque j'arrive avant tout le monde, j'ai droit au problème. A 9h15, lorsque les 200 salariés de la boite sont là et que l'activité SQL augmente, je suppose qu'il arrive que postgres ne flush pas tout de suite ses caches. Et donc, paradoxalement, c'est parce qu'il y a plus d'activité que ca va plus vite (en tout cas que ca n'entre pas en conflit avec les écritures de l'IMAP).
Alors comment j'en suis arrivé à cette conclusion ??? J'ai juste inversé les requêtes SQL et le requêtes IMAP, et là tout fonctionne.
Bon évidement c'est juste un patch qui ne corrige absolument pas le problème. Il va falloir tout réinstaller et séparer les RAIDs!
Bon ben au moins, y a une logique dans cette histoire. c'est déjà ça!
Etienne
Le 01/01/2011 09:52, SQLpro a écrit :
Bonjour,
en règle générale les machines virtuelles tuent les performances des SGBDR.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Bon tu avais raison...
Alors voila l'explication (enfin disons mon interprétation du problème).
lorsque je supprime des mails (sur mon client mail)
- j'exécute la suppression sur le serveur de mail
- j'exécute la suppression sur postgresql
le serveur imap et postgresql tournent tous les deux dans 2 machines
virtuelles séparées, mais... partage le même raid. (erreur !!!)
Donc lorsque j'exécute ma requêtes SQL, pas de chance, linux est en
train de supprimer les mails (physiquement). Postgres, pour qui, il n'y
a pas d'IO à ce moment décide lui aussi de flusher ses caches.
Et boum... c'est le bouchon.
Donc le matin lorsque j'arrive avant tout le monde, j'ai droit au problème.
A 9h15, lorsque les 200 salariés de la boite sont là et que l'activité
SQL augmente, je suppose qu'il arrive que postgres ne flush pas tout de
suite ses caches. Et donc, paradoxalement, c'est parce qu'il y a plus
d'activité que ca va plus vite (en tout cas que ca n'entre pas en
conflit avec les écritures de l'IMAP).
Alors comment j'en suis arrivé à cette conclusion ???
J'ai juste inversé les requêtes SQL et le requêtes IMAP, et là tout
fonctionne.
Bon évidement c'est juste un patch qui ne corrige absolument pas le
problème. Il va falloir tout réinstaller et séparer les RAIDs!
Bon ben au moins, y a une logique dans cette histoire. c'est déjà ça!
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Bon tu avais raison...
Alors voila l'explication (enfin disons mon interprétation du problème). lorsque je supprime des mails (sur mon client mail) - j'exécute la suppression sur le serveur de mail - j'exécute la suppression sur postgresql
le serveur imap et postgresql tournent tous les deux dans 2 machines virtuelles séparées, mais... partage le même raid. (erreur !!!)
Donc lorsque j'exécute ma requêtes SQL, pas de chance, linux est en train de supprimer les mails (physiquement). Postgres, pour qui, il n'y a pas d'IO à ce moment décide lui aussi de flusher ses caches. Et boum... c'est le bouchon.
Donc le matin lorsque j'arrive avant tout le monde, j'ai droit au problème. A 9h15, lorsque les 200 salariés de la boite sont là et que l'activité SQL augmente, je suppose qu'il arrive que postgres ne flush pas tout de suite ses caches. Et donc, paradoxalement, c'est parce qu'il y a plus d'activité que ca va plus vite (en tout cas que ca n'entre pas en conflit avec les écritures de l'IMAP).
Alors comment j'en suis arrivé à cette conclusion ??? J'ai juste inversé les requêtes SQL et le requêtes IMAP, et là tout fonctionne.
Bon évidement c'est juste un patch qui ne corrige absolument pas le problème. Il va falloir tout réinstaller et séparer les RAIDs!
Bon ben au moins, y a une logique dans cette histoire. c'est déjà ça!
Etienne
SQLpro
Le 04/01/2011 10:35, Etienne a écrit :
Le 01/01/2011 09:52, SQLpro a écrit :
Bonjour,
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Bon tu avais raison...
Alors voila l'explication (enfin disons mon interprétation du problème). lorsque je supprime des mails (sur mon client mail) - j'exécute la suppression sur le serveur de mail - j'exécute la suppression sur postgresql
le serveur imap et postgresql tournent tous les deux dans 2 machines virtuelles séparées, mais... partage le même raid. (erreur !!!)
Donc lorsque j'exécute ma requêtes SQL, pas de chance, linux est en train de supprimer les mails (physiquement). Postgres, pour qui, il n'y a pas d'IO à ce moment décide lui aussi de flusher ses caches. Et boum... c'est le bouchon.
Donc le matin lorsque j'arrive avant tout le monde, j'ai droit au problème. A 9h15, lorsque les 200 salariés de la boite sont là et que l'activité SQL augmente, je suppose qu'il arrive que postgres ne flush pas tout de suite ses caches. Et donc, paradoxalement, c'est parce qu'il y a plus d'activité que ca va plus vite (en tout cas que ca n'entre pas en conflit avec les écritures de l'IMAP).
Alors comment j'en suis arrivé à cette conclusion ??? J'ai juste inversé les requêtes SQL et le requêtes IMAP, et là tout fonctionne.
Bon évidement c'est juste un patch qui ne corrige absolument pas le problème. Il va falloir tout réinstaller et séparer les RAIDs!
Bon ben au moins, y a une logique dans cette histoire. c'est déjà ça!
Au minimum si tu veut rester en virtualisation et avoir des perfs, il faut faire du disque "pass through" et créer des LUN indépendantes sur des disques physiques à usage exclusif de la base. En sus, éviter le RAID 5 ou 6 et toutes combinaisons (50 par exemple).
A +
Etienne
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Le 04/01/2011 10:35, Etienne a écrit :
Le 01/01/2011 09:52, SQLpro a écrit :
Bonjour,
en règle générale les machines virtuelles tuent les performances des
SGBDR.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Bon tu avais raison...
Alors voila l'explication (enfin disons mon interprétation du problème).
lorsque je supprime des mails (sur mon client mail)
- j'exécute la suppression sur le serveur de mail
- j'exécute la suppression sur postgresql
le serveur imap et postgresql tournent tous les deux dans 2 machines
virtuelles séparées, mais... partage le même raid. (erreur !!!)
Donc lorsque j'exécute ma requêtes SQL, pas de chance, linux est en
train de supprimer les mails (physiquement). Postgres, pour qui, il n'y
a pas d'IO à ce moment décide lui aussi de flusher ses caches.
Et boum... c'est le bouchon.
Donc le matin lorsque j'arrive avant tout le monde, j'ai droit au problème.
A 9h15, lorsque les 200 salariés de la boite sont là et que l'activité
SQL augmente, je suppose qu'il arrive que postgres ne flush pas tout de
suite ses caches. Et donc, paradoxalement, c'est parce qu'il y a plus
d'activité que ca va plus vite (en tout cas que ca n'entre pas en
conflit avec les écritures de l'IMAP).
Alors comment j'en suis arrivé à cette conclusion ???
J'ai juste inversé les requêtes SQL et le requêtes IMAP, et là tout
fonctionne.
Bon évidement c'est juste un patch qui ne corrige absolument pas le
problème. Il va falloir tout réinstaller et séparer les RAIDs!
Bon ben au moins, y a une logique dans cette histoire. c'est déjà ça!
Au minimum si tu veut rester en virtualisation et avoir des perfs, il
faut faire du disque "pass through" et créer des LUN indépendantes sur
des disques physiques à usage exclusif de la base. En sus, éviter le
RAID 5 ou 6 et toutes combinaisons (50 par exemple).
A +
Etienne
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Bon tu avais raison...
Alors voila l'explication (enfin disons mon interprétation du problème). lorsque je supprime des mails (sur mon client mail) - j'exécute la suppression sur le serveur de mail - j'exécute la suppression sur postgresql
le serveur imap et postgresql tournent tous les deux dans 2 machines virtuelles séparées, mais... partage le même raid. (erreur !!!)
Donc lorsque j'exécute ma requêtes SQL, pas de chance, linux est en train de supprimer les mails (physiquement). Postgres, pour qui, il n'y a pas d'IO à ce moment décide lui aussi de flusher ses caches. Et boum... c'est le bouchon.
Donc le matin lorsque j'arrive avant tout le monde, j'ai droit au problème. A 9h15, lorsque les 200 salariés de la boite sont là et que l'activité SQL augmente, je suppose qu'il arrive que postgres ne flush pas tout de suite ses caches. Et donc, paradoxalement, c'est parce qu'il y a plus d'activité que ca va plus vite (en tout cas que ca n'entre pas en conflit avec les écritures de l'IMAP).
Alors comment j'en suis arrivé à cette conclusion ??? J'ai juste inversé les requêtes SQL et le requêtes IMAP, et là tout fonctionne.
Bon évidement c'est juste un patch qui ne corrige absolument pas le problème. Il va falloir tout réinstaller et séparer les RAIDs!
Bon ben au moins, y a une logique dans cette histoire. c'est déjà ça!
Au minimum si tu veut rester en virtualisation et avoir des perfs, il faut faire du disque "pass through" et créer des LUN indépendantes sur des disques physiques à usage exclusif de la base. En sus, éviter le RAID 5 ou 6 et toutes combinaisons (50 par exemple).
A +
Etienne
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
helios
SQLpro a écrit :
Le 04/01/2011 10:35, Etienne a écrit :
Le 01/01/2011 09:52, SQLpro a écrit :
Bonjour,
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Bon tu avais raison...
Alors voila l'explication (enfin disons mon interprétation du problème). lorsque je supprime des mails (sur mon client mail) - j'exécute la suppression sur le serveur de mail - j'exécute la suppression sur postgresql
le serveur imap et postgresql tournent tous les deux dans 2 machines virtuelles séparées, mais... partage le même raid. (erreur !!!)
Donc lorsque j'exécute ma requêtes SQL, pas de chance, linux est en train de supprimer les mails (physiquement). Postgres, pour qui, il n'y a pas d'IO à ce moment décide lui aussi de flusher ses caches. Et boum... c'est le bouchon.
Donc le matin lorsque j'arrive avant tout le monde, j'ai droit au problème. A 9h15, lorsque les 200 salariés de la boite sont là et que l'activité SQL augmente, je suppose qu'il arrive que postgres ne flush pas tout de suite ses caches. Et donc, paradoxalement, c'est parce qu'il y a plus d'activité que ca va plus vite (en tout cas que ca n'entre pas en conflit avec les écritures de l'IMAP).
Alors comment j'en suis arrivé à cette conclusion ??? J'ai juste inversé les requêtes SQL et le requêtes IMAP, et là tout fonctionne.
Bon évidement c'est juste un patch qui ne corrige absolument pas le problème. Il va falloir tout réinstaller et séparer les RAIDs!
Bon ben au moins, y a une logique dans cette histoire. c'est déjà ça!
Au minimum si tu veut rester en virtualisation et avoir des perfs, il faut faire du disque "pass through" et créer des LUN indépendantes sur des disques physiques à usage exclusif de la base. En sus, éviter le RAID 5 ou 6 et toutes combinaisons (50 par exemple).
A +
"éviter le RAID5 ou 6" voila un conseil de pro ne pas utiliser de machine Pro
si on etait dans le monde des motos le "pro" donnerait comme conseil "pour allez loin ne demarer pas le moteur pedalez plutot vous consommerez moins d'essence donc irez plus loin" :-)
SQLpro a écrit :
Le 04/01/2011 10:35, Etienne a écrit :
Le 01/01/2011 09:52, SQLpro a écrit :
Bonjour,
en règle générale les machines virtuelles tuent les performances des
SGBDR.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Bon tu avais raison...
Alors voila l'explication (enfin disons mon interprétation du problème).
lorsque je supprime des mails (sur mon client mail)
- j'exécute la suppression sur le serveur de mail
- j'exécute la suppression sur postgresql
le serveur imap et postgresql tournent tous les deux dans 2 machines
virtuelles séparées, mais... partage le même raid. (erreur !!!)
Donc lorsque j'exécute ma requêtes SQL, pas de chance, linux est en
train de supprimer les mails (physiquement). Postgres, pour qui, il n'y
a pas d'IO à ce moment décide lui aussi de flusher ses caches.
Et boum... c'est le bouchon.
Donc le matin lorsque j'arrive avant tout le monde, j'ai droit au
problème.
A 9h15, lorsque les 200 salariés de la boite sont là et que l'activité
SQL augmente, je suppose qu'il arrive que postgres ne flush pas tout de
suite ses caches. Et donc, paradoxalement, c'est parce qu'il y a plus
d'activité que ca va plus vite (en tout cas que ca n'entre pas en
conflit avec les écritures de l'IMAP).
Alors comment j'en suis arrivé à cette conclusion ???
J'ai juste inversé les requêtes SQL et le requêtes IMAP, et là tout
fonctionne.
Bon évidement c'est juste un patch qui ne corrige absolument pas le
problème. Il va falloir tout réinstaller et séparer les RAIDs!
Bon ben au moins, y a une logique dans cette histoire. c'est déjà ça!
Au minimum si tu veut rester en virtualisation et avoir des perfs, il
faut faire du disque "pass through" et créer des LUN indépendantes sur
des disques physiques à usage exclusif de la base. En sus, éviter le
RAID 5 ou 6 et toutes combinaisons (50 par exemple).
A +
"éviter le RAID5 ou 6" voila un conseil de pro ne pas utiliser de
machine Pro
si on etait dans le monde des motos le "pro" donnerait comme conseil
"pour allez loin ne demarer pas le moteur pedalez plutot vous
consommerez moins d'essence donc irez plus loin" :-)
en règle générale les machines virtuelles tuent les performances des SGBDR. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8234/langage-sql-norme/sgbdr-et-virtualisation/
Bon tu avais raison...
Alors voila l'explication (enfin disons mon interprétation du problème). lorsque je supprime des mails (sur mon client mail) - j'exécute la suppression sur le serveur de mail - j'exécute la suppression sur postgresql
le serveur imap et postgresql tournent tous les deux dans 2 machines virtuelles séparées, mais... partage le même raid. (erreur !!!)
Donc lorsque j'exécute ma requêtes SQL, pas de chance, linux est en train de supprimer les mails (physiquement). Postgres, pour qui, il n'y a pas d'IO à ce moment décide lui aussi de flusher ses caches. Et boum... c'est le bouchon.
Donc le matin lorsque j'arrive avant tout le monde, j'ai droit au problème. A 9h15, lorsque les 200 salariés de la boite sont là et que l'activité SQL augmente, je suppose qu'il arrive que postgres ne flush pas tout de suite ses caches. Et donc, paradoxalement, c'est parce qu'il y a plus d'activité que ca va plus vite (en tout cas que ca n'entre pas en conflit avec les écritures de l'IMAP).
Alors comment j'en suis arrivé à cette conclusion ??? J'ai juste inversé les requêtes SQL et le requêtes IMAP, et là tout fonctionne.
Bon évidement c'est juste un patch qui ne corrige absolument pas le problème. Il va falloir tout réinstaller et séparer les RAIDs!
Bon ben au moins, y a une logique dans cette histoire. c'est déjà ça!
Au minimum si tu veut rester en virtualisation et avoir des perfs, il faut faire du disque "pass through" et créer des LUN indépendantes sur des disques physiques à usage exclusif de la base. En sus, éviter le RAID 5 ou 6 et toutes combinaisons (50 par exemple).
A +
"éviter le RAID5 ou 6" voila un conseil de pro ne pas utiliser de machine Pro
si on etait dans le monde des motos le "pro" donnerait comme conseil "pour allez loin ne demarer pas le moteur pedalez plutot vous consommerez moins d'essence donc irez plus loin" :-)
