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é à 2 (+0/-0).

          Bon ben,… rien. J'ai d'abord été prudent : les index sur les tables les plus sollicitées, finalement la base étant toute petite j'ai fait un repack sur l'ensemble.
          Je n'ai pas joué à déplacer les tables et indexs, ça vaut le coup ?

    • [^] # 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é à 3 (+1/-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)

    • [^] # Re: Les index

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

      Merci merci
      Je ne vois pas trop pourquoi des requêtes deviendraient problématiques en changeant de machine. Tu veux dire pour identifier des trous dans l'index ?

      (moi aussi j'adore le Génie des alpages)

      • [^] # Re: Les index

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

        Comme je ne sais pas exactement ce que tu veux dire par une copie du système de fichier (un bête cp/rsync ?) ni si ça concerne aussi la base de données.

        Je ne connais pas suffisamment Postgres pour avoir la moindre certitude, mais j'imagine qu'il existe des possibilités pour qu'une copie du système de fichier puisse avoir changé un détail qu'utilise Postgres et qui ferait que les index ne sont plus utilisé.

        Donc
        1. Est-ce que les index sont toujours en place ?
        2. Est-ce que les index sont utilisés ? (il y a la possibilité de demander à postgres de logger les requêtes)

        Il me semble qu'un backup (ou restore?) de db fait avec les mauvaises options peut aussi faire perdre les index au passage.

        Outre les problèmes de surbooking cités ailleurs, les soucis d'index sont un bel exemple de cause de ralentissements donc même si peu probable avec la méthode suivie, ça ne coute pas grand chose à verifier.

        Ah oui, et si tu veux voir un peu où se perdent les perfs, y'a pgbadger qui permet de voir quelles sont les requêtes potentiellement problématiques.

        • [^] # Re: Les index

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

          Merci.
          L'hébergeur m'a parlé d'une copie du système de fichier, sûrment parce qu'il devait changer de pool VMWare, d'une grappe de serveur à une autre, peut-être localisée ailleurs.

        • [^] # Re: Les index

          Posté par  . Évalué à 2 (+0/-0). Dernière modification le 21 novembre 2024 à 17:54.

          (doublon)

  • # 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.

    • [^] # Re: changer de machine "VMware"

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

      L'hébergeur me l'a proposé hier. Je le ferai, après avoir vérifié la bdd, faudrait pas que ce 2e changement de machine dégrade encore plus les choses :-)

  • # points à vérifier

    Posté par  (site web personnel) . Évalué à 5 (+4/-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.

    • [^] # Re: points à vérifier

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

      effectivement, souvent, les hyperviseurs sont configurés pour faire du surbooking.

      • [^] # Re: points à vérifier

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

        Je vais regarder ça, merci du tuyau, je n'aurais pas pensé au surbooking.
        Postgres et Odoo sont sur la même machine virtuelle, donc pas de réseau.

        • [^] # Re: points à vérifier

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

          Sauf incompréhension, pour choper le CPU Ready il faut être l'hébergeur. Or je suis dans la machine virtuelle. Il y a bien des outils à lancer sur la VM mais il faut d'abord avoir un tas d'infos sur les machine hôtes de l'hyperviseur.
          Non ?
          Si ?

          • [^] # Re: points à vérifier

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

            vmstat te donne l'info :

            :~$ vmstat 1 10
procs ----------mémoire---------- -échange- -----io---- -système- ------cpu-----
 r  b   swpd  libre tampon  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0 1242252 1695924 1706456 6132220    0    1     4     9    1    3  3  1 95  0  0
 1  0 1242252 1690372 1706480 6132364    0    0     0   232 4337 7092  4  2 94  0  0
 0  0 1242252 1689796 1706480 6132404    0    0     0     0 3459 5111  5  2 93  0  0
 1  0 1242252 1695340 1706480 6132420    0    0     0     0 3262 4646  5  1 94  0  0

            The final field st represents the percentage of time a virtual CPU waits for a real CPU while the hypervisor is servicing another virtual processor. Essentially, the steal time cycle counts the amount of time that your virtual machine is ready to run but could not run due to other virtual machines competing for the CPU.

  • # DNS ?

    Posté par  . Évalué à 3 (+0/-0). Dernière modification le 21 novembre 2024 à 19:17.

    tu as changé d'IP, tu as mis à jour tes enregistrements DNS pour que ton serveur odoo trouve toujours ta base de données, que l'utilisateur venant d'une autre IP puisse toujours se connecter ?

    tu as mis à jours les certificats avec la nouvelle IP ?

    une firewall configuré qui laissait passer des flux venant de l'ancienne IP vers un equipement externe ou une source de données qui ne serait plus autorisé à cause de la nouvelle IP ?

    • [^] # Re: DNS ?

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

      Oui les DNS sont à jours. Mais pourquoi les certificats ?

      • [^] # Re: DNS ?

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

        parce que parfois on met les IPs dans le certificat pour quand meme faire du SSL/TLS quand on se connecte via l'IP du serveur plutot que son nom DNS

        • [^] # Re: DNS ?

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

          Ah oui. En principe je ne le fais pas, mais j'ai vérifié quand même (RAS). Merci pour l'idée.

          • [^] # Re: DNS ?

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

            Est ce que tu utilise un nom d'hôte pour la base? Est ce que l'application tente une résolution en ipv6, puis seulement après une en ipv4?

            Un LUG en Lorraine : https://enunclic-cappel.fr

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.