Re: Lenteur de postgresSQL 7.4

Le jeudi 24 mai 2012 11:19:22, Alain a écrit :
> Bonjour,
>
> Merci pour votre post. J'essaie de vous répondre entre les lignes :
>
> On Thu, 24 May 2012 07:53:06 +0000
>
> Cousin Florence <fcousin(at)sopragroup(dot)com> wrote:
> > Bonjour,
> >
> > Tout d'abord, à votre place, je ferais tout de suite une copie des
> > fichiers de la première base (celle sur laquelle vous avez eu des
> > problèmes de disque), on ne sait jamais :
> > http://wiki.postgresql.org/wiki/Corruption
>
> Bien noté, mais c'est peut-être un peu tard et il ne semble pas que
> j'ai perdu de données, seul le temps de traitement est insupportable.
>
> > Et idem pour celle en production.
> >
> > Ensuite, il est assez difficile de suivre l'ordre des événements :
> > 1. un traitement exceptionnel de mise à jour a eu lieu
>
> OUI, traitement consistant à mettre à jour la table "articles", à
> calculer un HT réduit pour la partie à 5.5% de façon à ce qu'avec un
> calul à 7% le TTC soit inchangé et à enregistrer la modification dans
> une table "historique des prix". Ceci pour 800 à 850.000 articles.
>
> > 2. au cours de ce traitement, vous avez eu des erreurs matérielles sur le
> > disque
>
> Surpris par la lenteur du traitement, j'ai visualisé les fichiers de
> log, puis lancé dmesg qui indiquait des erreurs incorrigibles. Rien ne
> me permettait de voir si c'était sur la partie BD ou une autre.
> Considérant que ce pouvait être la BD j'ai transféré la base sur une
> autre PC en réseau, ou Postgres était déja installé et qui était
> pratiquement inutilisé.
>
> > 3. vous avez fait un pgdump de la base, et réimporté le dump sur un autre
> > PC
>
> Exact, après avoir étoffée la mémoire en passant de 512MO à 1GO.
>
> > 4. vous avez réimporté le dump sur un autre PC (virtualisé)
>
> Exact, les traitements même minimes continuaient à prendre énormément
> de temps et le client doit changer prochainement de système. J'ai donc
> contacté un partenaire de ce changemnt pour voir si'il avait une
> solution. Il a proposé une partition virtualisée sur un PC qui est, je
> crois, sous SQLServer (l'application tourne sous Mandrake 10.1)
>
> > Sur quel(s) environnement(s) avez-vous fait le vacuum analyse?
>
> Sur les deux, PC Mdk 10.1 en réseau, et en virtualisation.
>
> > Que voulez-vous dire par : "des phénomènes de traitement
> > exécuté que partiellement."?
>
> Par exemple, lors d'une séance de crédits pour des retours, le
> traitement semble s'être effectué normalement (Impression des avoirs,
> enregistrement dans les mouvements, mais la zone "stock retours" n'a
> pas été mise à jour.
>
> > Quel est le serveur actuellement en production? (le premier, le 2ème
> > (réseau), le 3ème(virtualisé))?
>
> Compte tenu que les traitements étaient aussi longs et que de plus
> j'avais des doutes sur leur fiabilité, je suis repassé à la solution
> 2 : PC sous Mdk 10.1 en réseau.
>
> > Depuis combien de jours de production avez-vous eu le problème de disque
> > (plusieurs semaines?)
>
> Ça doit faire actuemllement environ 6 semaines.
>
> > Quelle est la requête qui prend 2 jours? Avez-vous fait un explain
> > dessus? Si oui, cela donne quoi? (index utilisés ou non, estimation
> > réalise ou pas?)
>
> Ce n'est pas une seule requête, c'est un programme Cobol qui en
> exécute plusieurs. Ce matin, entre 9h25 et 10h09, la sortie d'un Bon de
> Livraison de 284 lignes a pris 44 minutes ! L'application tournait
> comme une horloge suisse depuis environ 10 ans et ce changement subit
> des temps de traitement m'est inexplicable : S'il y a eu des erreurs
> dans la BD, elle a été reconstruite 2 ou 3 fois et je pense que
> pg_restore ne laisse pas passer grand chose.
>
> Merci pour les idées que vous pourriez avoir : où chercher, avec
> quelle commande ?
>

Il existe de très nombreuses causes possibles.
Vous devez lister tous les éléments qui ont été modifiés lors du changement de
comportement de l'application.

Consacrer du temps à la migration sera peut-être plus rapide et plus productif
que de tenter de maintenir un serveur obsolète.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation