Forum Programmation.SQL Gros ralentissement sur une base Postgresql 10

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
4
19
nov.
2024

Bonjour tout le monde
J'ai un ralentissement très bizarre sur une base de données… besoin d'idées.

C'est un serveur Odoo 10 et Postgresql 10 sur Ubuntu 18.04 dans un VPS assez gros (8 coeurs, 16 Go de Ram). Le VPS était sous VMWare, l'hébergeur l'a déplacé sur un autre VMWare. Le déplacement a été fait en copiant le système de fichiers, pas en déplaçant ou copiant l'image disque. Migration à froid donc. On a aussi changé d'IP.
Depuis il y a un très gros ralentissement dès que l'ERP Odoo a besoin d'ouvrir des articles: Odoo gère aussi le site ecommerce, et une page web d'article met près de 5 secondes à s'afficher, en backend la moindre recherche dans les articles (ou dans les lignes de commandes) prend de 30 à 120 secondes. Les autres pages du site (blog, à propos, accueil, …) et les autres menus de gestion ont un temps de réponse normaux. Il y a très peu d'articles, environ 4000 avec les variantes.

J'ai tout examiné, il y a eu d'autres petits problèmes, mais sur Postgresql on ne trouve rien, c'est clean. Et c'est la panne sèche aux idées. Des pistes quelqu'un ?

  • # quelques pistes

    Posté par  . Évalué à 6 (+4/-0).

    1. voir si les disques de la VM cible sont équivalent aux disques de la VM source en terme de perfs.
    2. Vérifier que le vaacum PostgreSQL se déroule bien. Il est possible que le changement de serveur ait perturbé la bonne exécution de celui-ci (ou alors il ne s'est plus exécuté depuis longtemps). Si ta base fait beaucoup de suppression/insertion de données, tu te retrouve avec un gruyère à la place d'une BDD, ça occupe de la place pour rien, et avec le temps, les temps d'accès augmentent considérablement( ça m'est arrivé plusieurs fois).

    • [^] # Re: quelques pistes

      Posté par  . Évalué à 3 (+1/-0).

      Ah .. je me rappelle aussi d'une commande passée régulièrement pour réorganiser les tables, mais je ne sais plus si c'est une commande intégrée à postgres ou si elle avait été développée pour le cas spcifique de l'application. C'est loin donc je ne me rappelle plus, et je n'ai plus accès au serveur, donc je ne peux pas donner plus de détails : d'autres pourront confirmer. Sinon voir la log des diverses couches pour voir ce que ça retourne (BDD, application, etc ..).

      • [^] # Re: quelques pistes

        Posté par  (site web personnel) . Évalué à 4 (+2/-0).

        https://reorg.github.io/pg_repack/ ?
        remove bloat from tables and indexes, and optionally restore the physical order of clustered indexes. Unlike CLUSTER and VACUUM FULL it works online, without holding an exclusive lock on the processed tables during processing. pg_repack is efficient to boot, with performance comparable to using CLUSTER directly.

        faut trouver les bonnes options ;-)

    • [^] # Re: quelques pistes

      Posté par  . Évalué à 4 (+2/-0).

      Merci de ta réponse.
      1. Les disques sont un peu plus lents en effet
      2. L'utilitaire vacuumdb en mode analyse n'a rien trouvé. C'est une toute petite base par rapport aux capacités de Postgres.

      Ce qui me laisse à court d'idées — sauf des idées ésotériques — c'est le ralentissement aussitôt après la migration et qui semble lié a une seule table (la base Odoo en contient des centaines).

    • [^] # Re: quelques pistes

      Posté par  . Évalué à 2 (+0/-0).

      Comme la base n'a pas l'air très grande, voici une autre idée pour diagnostiquer (ce n'est pas forcément une solution à long terme) : mettre des buffers suffisamment gros pour que la base soit entièrement en RAM. Ainsi, si le problème est au niveau du stockage ou sur l'alignement de la partition, ça devrait redevenir rapide. Si le problème est au niveau des CPUs ou d'index corrompus, le problème persistera.

  • # Les index

    Posté par  . Évalué à 4 (+3/-0).

    Hello,

    A verifier a tout hasard, possible qu'il aient ete corrompus pour une raison x ou y, et que l'optimiseur de requete les zappe.

    Sinon, plus globalement, pour avoir une petite idee de ce qui peche, il faut d'abord identifier la (ou les) requete(s) problematique(s), puis tu peux les rejouer avec explain/analyze pour identifier ce qui cause le ralentissement.

    ++
    Gi)

  • # Pg_activity pour investiguer, mais pas que.

    Posté par  . Évalué à 4 (+3/-0).

    Je peux te conseiller d'utiliser cet outil pour investiguer les requêtes longues https://github.com/dalibo/pg_activity

    Autres outils pratique : https://www.postgresql.org/docs/current/pgstatstatements.html
    (À activer dans postgresql.conf avec restart de postgres)

    Enfin, peut-être revoir les config de ton postgres avec https://pgtune.leopard.in.ua/
    (Peut-être une meilleure optimisation à faire sur la nouvelle machine).

  • # changer de machine "VMware"

    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 19 novembre 2024 à 22:36.

    Demande à changer de machine puisque c'est ce qui a déclenché le problème.
    Cette machine a peut être un problème de disque ou san.

  • # points à vérifier

    Posté par  (site web personnel) . Évalué à 4 (+3/-0).

    Vérifier la latence réseau entre l'applicatif odoo et le serveur pg, en environnement virtualisé, il y a des surprises des fois. Ils sont sur une même vm ? Ou séparés ?

    Pense aussi à regarder le "CPU Ready" de ta vm : tu dis qu'elle a 8 coeurs, si le serveur hôte est plus sollicité ou dispose de moins de coeurs que le précédent, cela peut jouer : quand vmware veut faire tourner ta vm, il doit attendre d'avoir 8 coeurs disponibles. Vouloir mettre trop de coeurs sur une vm n'est pas toujours une bonne idée, surtout que ta base de données ne semble pas énorme.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.