Discussion :

[Kunai]

Bonsoir,


En environnement de prod, je tourne avec 2 frontaux web et un master MySQL derrière. Chaque serveur web est également slave du master MySQL (seulement sur une base, ils ont aussi des bases locales). Le problème est celui-ci, au même moment sur les 2 slaves, le process mysqld se met à consommer énormément de CPU sans qu'aucune requête n'aie planté, juste du simple fait de la réplication (une fois celle-ci désactivé, le serveur mysql redémarré, l'occupation processeur est normale). A noter qu'au départ les 3 serveurs étaient en 5.0.45 et que maintenant le master est toujours en 5.0.45 mais les slaves sont en 5.0.51a.

Quelqu'un aurait déjà été confronté à ce genre de problème ? Peut-il s'agir d'un paramètrage des master / slaves qui diffèreraient, d'un problème lors de la lecture du fichier bin ?

Edit: après avoir laissé tourner une journée l'un des serveurs avec la réplication désactivé, sans requête effectuée, le daemon mysqld s'affole à nouveau donc la réplication n'est pas en cause... pas de requête, pas de réplication, génération spontanée de bug ?

[Hervé Saladin]

J'ai eu un problème de surcharge mais avec une architecture web "classique" en 3 tiers (client - serveur web - serveur de données).
Le problème venait d'une application qui exécutait des requêtes trop consommatrices, mais sans qu'elles soient fausses cela-dit.
Pour trouver laquelle, j'ai temporairement désactivé les applications unes à unes en les commentant dans le httpd.conf de apache. Quand la charge est revenue à la normale, je savais que la coupable était l'application qui était désactivée à ce moment là.
Evidement, le problème est que ça nécessite une petite interruption de service ... si tu es en prod je ne sais pas si tu peux te le permettre ... ? Si tu ne peux pas, tu peux peut-être essayer de faire un clone de ton serveur de prod pour le martyriser tranquille. Tu dois trouver des outils pour solliciter artificiellement les applis installées dessus et faire de tests de montée en charge.

[Kunai]

A vrai dire, le plupart des requêtes exécutées ont été testée et retestées. Le fait que le problème ne soit pas lié à la réplication mais intervienne au même moment quasiment sur les 2 serveurs nous incite à regarder du côté des fichiers logs (plus particulièrement de leur taille). Le flush des logs cet après midi a l'air d'avoir des résultats mais il est probable que le temps nous confirme ou nous infirme que le fichier log était en cause (pour info les 2 fichiers logs approchaient les 6 Go).

Stay tuned donc