MySQL Server has gone away : timeout de 60 secondes ?

Version imprimable

05/10/2011, 07h38
kaboume

MySQL Server has gone away : timeout de 60 secondes ?

Bonjour,

J'ai un soucis depuis plusieurs jours que je n'arrive pas à résoudre.

J'ai une interface Web PHP qui attaque une base de données MySQL. Auparavant , quand cette base web était en MyISAM tout fonctionnait bien mais depuis que nous avons basculé sur une base innodb (même structure / données car dump de la MyISAM), j'ai le problème suivant :
Lorsqu'une requête exécutée à partir de l'interface WEB PHP dépasse les 60 secondes, j'ai une FATAL Error me disant "MySQL Server has gone away".

J'ai essayé de résoudre le problème en augmentant les valeurs de mysql.connect_timeout et default_socket_timeout dans le PHP.INI mais rien n'y fait.
Au niveau du serveur MySQL, j'ai bien un wait_timeout de 8 heures et un interactive_timeout de 8 heures.

Pour info, j'ai fixé un set_time_limit à plusieurs minutes pour mon script PHP.

Je n'ai pas touché au paramètre MySQL max_allowed_packet car mon script PHP appelle une procédure stockée MySQL donc très peu de données envoyées au serveur MySQL.

Je suis un peu à court d'idées maintenant :roll:... Est-ce que vous sauriez d'où vient ce timeout de 60 secondes ?

Merci d'avance!
05/10/2011, 09h25
stealth35

c'est possible que la requete fasse planter le serveur, t'as regarde les logs Mysql voir le serveur s'est éteint ?
05/10/2011, 09h30
CinePhil

60 secondes pour une requête ? Je ne voudrais pas être à la place de l'utilisateur qui attend l'affichage des données sur la page web !

Il faudrait peut-être voir si la requête est optimisée et si le schéma de la BDD est normalisé.
On peut voir la requête qui dure aussi longtemps et la structure des tables impliquées ainsi que le nombre de leurs lignes ?
05/10/2011, 09h51
kaboume

Mer'ci pour vos réponses.

Effectivement, une requête ne devrait pas prendre autant de temps mais ce sont des reporting qui nécessitent pas mal de temps à s'exécuter (les requêtes ont déjà été pas mal optimisées).
05/10/2011, 10h00
stealth35

et donc quid des logs ?
05/10/2011, 10h02
kaboume

Rien dans les logs de MySQL.
05/10/2011, 10h06
stealth35

Citation:

Envoyé par kaboume

Rien dans les logs de MySQL.

t'as bien configuer les logs (idem pour les slow queries)
05/10/2011, 10h09
kaboume

yes.
05/10/2011, 10h14
stealth35

Citation:

Envoyé par kaboume

yes.

si le serveur te met se message la, t'as forcement des logs de déconnexion, montre un bout de tes logs
05/10/2011, 10h34
CinePhil

Citation:

Envoyé par kaboume

(les requêtes ont déjà été pas mal optimisées).

Si tu le dis... :roll:

Quelle masse de données est traitée par cette requête ? Combien de millions de lignes ?
Les tables sont-elles correctement indexées ? Le serveur est-il correctement dimensionné ?

Bref, sans plus d'informations, on ne peut pas t'aider.
05/10/2011, 10h39
kaboume

Là c'est surtout le problème de problème de timeout qu'il faut que je résolve au plus vite, problème que je n'avais pas il y a quelques jour sur la myISAM.

Pour l'optimisation des requêtes, il y a sûrement du travail à faire mais je dois dire que ma priorité première est de rétablir le service.
05/10/2011, 10h57
CinePhil

Et si l'optimisation de la requête qui plante résolvait du même coup ton problème de "server has gone away" ? :roll:
Si la requête ne s'exécute pas en 60 secondes mais ne serait-ce que 10 fois moins, le serveur n'aura pas le temps de s'en aller boire un café ! :P
05/10/2011, 11h01
stealth35

tu veux toujours pas montrer tes logs ?
05/10/2011, 11h50
kaboume

Si j'ai demandé à mon admin... j'attends...
05/10/2011, 11h57
CinePhil

Et la requête qui pose problème, tu dois aussi la demander à ton admin ?
05/10/2011, 12h04
kaboume

Non pas besoin, je l'ai mais c'est une procédure stockée assez complexe avec des connaissance fonctionnelles pour la comprendre.

J'essaierai de la ré optimiser... mais comme ça peut prendre du temps et que le problème du timeout de connexion est bloquant, c'est l'urgence.

Pour info, presque toutes les procédures stockées sont concernées.
10/10/2011, 10h57
kaboume

Je viens d'avoir accès au log de MySQL.
Rien de spécial dedans.
Aucune trace dans la log aux moments des "MySQL Server has gone away".
11/10/2011, 11h45
Aurélien LEQUOY

Citation:

quand cette base web était en MyISAM tout fonctionnait bien mais depuis que nous avons basculé sur une base innodb (même structure / données car dump de la MyISAM)

Citation:

Envoyé par kaboume

Non pas besoin, je l'ai mais c'est une procédure stockée assez complexe avec des connaissance fonctionnelles pour la comprendre.

J'essaierai de la ré optimiser... mais comme ça peut prendre du temps et que le problème du timeout de connexion est bloquant, c'est l'urgence.

Pour info, presque toutes les procédures stockées sont concernées.

Depuis quand on peux faire des proc stock avec MyIsam ?

Je dirais peux importe le fonctionnel étant donné que ton problème semble être purement techniques si tout était ok avec MyISAM.

quiz : temps de traitement avec MyISAM ?
12/10/2011, 11h20
kaboume

Merci pour ta réponse.

Citation:

Depuis quand on peux faire des proc stock avec MyIsam ?

Depuis pas mal de temps! Tu voulais peut-être parler des transactions ??

Citation:

Je dirais peux importe le fonctionnel étant donné que ton problème semble être purement techniques si tout était ok avec MyISAM.

C'est pour cela que je poste sur ce forum

Citation:

quiz : temps de traitement avec MyISAM ?

J'avais des temps de réponse un peu meilleurs mais qui pouvaient dépasser plusieurs minutes (pour les reportings) sans sortir en erreur.
12/10/2011, 11h36
CinePhil

Ton problème était urgent le 5 octobre. Nous sommes le 12 et il ne semble toujours pas résolu.
Tu aurais peut-être eu le temps, durant cette semaine, de nous poster un exemple de procédure qui pose problème et nous aurions peut-être pu t'aider à l'optimiser.
12/10/2011, 16h48
kabkab

Bonjour,
Quand il s'agit de n'importe quelle requête MySql le serveur est sollicité (un peu ou beaucoup) selon la complexité de cette requête.
Dans le cas de requêtes SELECT (simples) sur un champ non indexé, il y a un parcours de la totalité de la table ce qui demande un peu de travail au serveur. Alors, s'il s'agit de jointures avec l'utilisation de fonctions du style MAX ou SUBSTRING... il y a plus de travail à faire.
Quand il s'agit de procédure stockées, le travail est directement demandé en bloc au serveur et c'est normal qu'il passe du temps dessus.
Dans mon cas particulier, je devais lancer une procédure stockée qui se contentait juste de changer la valeur d'un champ suivant la date de publication de l'enregistrement (c'est à dire suivant le contenu d'un autre champ). L'opération demandait juste 8 minutes mais avec les services interdits au public sinon mon serveur ralentissait et j'avais abouti à la même opération avec les services ouverts à pas moins de 37 minutes.
Cela va sans dire que je me suis fait rappeler à l'ordre par mon hébergeur qui me signalait que durant plus d'une demi-heure le serveur tournait autour de 75% de ressources CPU.
Tout cela pour dire que si ton opération est régulière il faudra penser à une autre méthode (par tranches) si c'est possible.
D'autre part, le moteur Innodb est plus gourmand en ressources système que MyIsam.

N'empêches, tant que l'on ne sait pas en quoi consiste ton opération, je ne pense pas que tu trouves beaucoup de réponses.