Bonjour,

Je rencontre un problème de performance sur une application en production. Il y a des gros traitements qui tournent le matin à partir de 6h et qui doivent se terminer vers 8h30 (en fonctionnement normal) Il y a egalement un grand nombre de connexion à ce moment là (j'usqu'à environ 230). Mais depuis le début janvier j'ai des problèmes avec ces traitements, on passe de 8h30 à parfois 11h et plus. Une simple requête d'insertion de log peut prendre jusqu'à 1m30...

Au niveau perf de la machine on a de la marge sur tout les aspects

Je sais pas en décrivant mon problème, si vous arriverez à m'aider ou me donner des pistes à exploiter mais ça fait un mois que je cherche donc je n'ai rien à perde d'essayer ici ^^

3 réponses


Bonjour,

Effectivement cela va être très difficile d'aider si on a pas un minimum d'info sur l'architecture, la structure de la base et la nature des opération effectuées.

De mon point de vue, il y a quand même 2 choses qui ressortent :

  • "on passe de 8h30 à parfois 11h et plus" : si le temps d'execution s'agrandie, c'est probablement parce que le nombre de données augmente, il faudrait voir si il n'y a pas possibilité de filtrer davantage les données afin d'éviter tout traitement illégitime;
  • "insertion de log" : tu parle de quels logs execatement ? parce que pour moi des logs ça doit être dans un fichier de logs, pas en base;
cid5420
Auteur

Bonjour,

Merci pour vos retours :)

Mysql (8.0.25) tourne sur un serveur debain 9.
il n'y a que des tables innodb
Les principales opérations se font le matin, on se connect à une api, on reçoit une réponse SOAP, on parse cette réponse (on enregistre en dbb cette phase pour reconstruire après), on met à jour nos items (env 450k)
Au niveau config mysql, j'ai modifier max_connections = 512
innodb_buffer_pool_size est par défaut (je me demande si je ne devrais pas l'augmenté)

La partie api a été écarté du problème, bien que j'avais du mal à savoir d'où ça pouvait venir car j'ai pris effectivement une mauvaise habitude d'enregistrer des logs en bdd (je ne le ferais plus, c'est aussi comme ça que l'on apprend ^^)

Sur le serveur, il y a un truc qui me dérrange... Au moment où je rédige cette réponse, tous les process sont terminés, il n'y a quasiment plus aucun mouvement mais mysql reste à +9Go de ram en utilisation... Je n'ai pas l'impression d'avoir remarqué ça avant le problème... De même au niveau %CPU, parfois ça monte à 300% (même si cette valeur ne signifie pas grand chose sur une VM) bref, c'est peut être un élément de réponse...

N'hésitez pas s'il manque des infos, je ne me rend pas trop compte de ce que vous avez besoin pour m'aider :/

OK Merci pour cette réponse,

Est-ce qu'il serait possible d'avoir un peu plus de détails sur les étapes suivantes stp :

  • on enregistre en dbb cette phase pour reconstruire après;
  • on met à jour nos items;

Qui fait ça ? un client PHP ou NodeJS ? MySQL directement ?

J'avoue que la volumétrie de donnée (450k) me donne un peu le vertige... vaut mieux avoir du solide derrière si on veut les traiter quotidiennement.

Côté "machine" c'est moins mon domaine donc je pourrai pas trop aider, je me pose juste la question : est-ce que la configuration actuelle du serveur MySQL est en adequation avec les capacité de la machine ? il y a peut être effecctivement quelque chose à faire sur les paramètres "innodb_buffer_pool_size" et "innodb_buffer_pool_instances".