Je suis la dernière version d'eva-web et j'ai des logs mysql douteux du style "Sep 09 02:30:13 65.55.208.251 (pid 5151) 2006 MySQL server has gone away" dans /tmp/mysql.log .
Côté serveur mysql, ben ... il tourne bien.
Par contre, mes pages sont hyper hyper lentes à charger, y compris côté backend.
Je suis la dernière version d'eva-web et j'ai des logs mysql douteux du
style "Sep 09 02:30:13 65.55.208.251 (pid 5151) 2006 MySQL server has
gone away" dans /tmp/mysql.log .
Côté serveur mysql, ben ... il tourne bien.
Par contre, mes pages sont hyper hyper lentes à charger, y compris côté
backend.
Je suis la dernière version d'eva-web et j'ai des logs mysql douteux du style "Sep 09 02:30:13 65.55.208.251 (pid 5151) 2006 MySQL server has gone away" dans /tmp/mysql.log .
Côté serveur mysql, ben ... il tourne bien.
Par contre, mes pages sont hyper hyper lentes à charger, y compris côté backend.
Je suis la dernière version d'eva-web et j'ai des logs mysql douteux du style "Sep 09 02:30:13 65.55.208.251 (pid 5151) 2006 MySQL server has gone away" dans /tmp/mysql.log .
Côté serveur mysql, ben ... il tourne bien.
Par contre, mes pages sont hyper hyper lentes à charger, y compris côté backend.
Une idée du pourquoi du comment???
A bientôt.
Ben oui ton hébergement a quelque chose a voir avec ce problème ... c'est typiquement la source du problème ( a confirmer ).
Donne nous plus d'infos sur ton hébergement, et la base de donnée, ainsi que le nombre de visiteurs / jours , les squelettes sont d'EVA sans aucunes modifications ?
tu utilises le système de stats de SPIP ?
tu as paramétré le cache a combien de temps sur tes pages ?
Ben oui ton hébergement a quelque chose a voir avec ce problème ... c'est typiquement la source du problème ( a confirmer ).
Donne nous plus d'infos sur ton hébergement,
Mon hébergeur est l'APINC. De leur côté, ils me disent que c'est mon squelette qui doit être gourmand.
et la base de donnée,
Mysql: Version du serveur: 5.0.32-Debian_7etch5-log
Le admin de l'APINC m'ont dis que c'était peut être une histoire d'optimisation des tables pour les requêtes.
D'après leurs critères, j'ai essayé quelques requêtes trouvées dans le mysql.logs, en direct dans phpmyadmin, et elles semblent très rapidement exécutées, donc ... bon.
les squelettes sont d'EVA sans aucunes modifications ?
J'utilise EVA avec son squelette de base.
Les seules modif' apportées sont que j'utilise le plugin expresso et que j'ai donc percolé certaines pages ... puisque justement c'était bien lent et que j'avais des logs mysql douteux.
tu utilises le système de stats de SPIP ?
Je l'ai désactivé sur les conseils des admin de l'APINC.
tu as paramètré le cache a combien de temps sur tes pages ?
Je n'ai pas changé le temps mis par défaut sur eva-web. D'un autre côté, je n'en vois pas de mis non plus sur les quelques pages que je viens de regarder: rubrique.html , article.html , rubrique_normale.html
Que dire de plus ...
Merci pour cette demande d'éclaircissement en tous cas.
Si tu utilises un boucle complexe ou un plugin particulier la
connexion peut partir en carafe.
Pour savoir il essayer de determiner quelle page est à la source du
pb, sachant que dans ce cas spip.log et mysql.log seront de peu
d'utilité à priori.
En fait, je ne connais pas de pages de mon site qui soit rapide à charger.
Cela voudrait dire que l'ensemble des pages du plugin eva-web utilisent des boucles complexes??
Merci de m'aider à avancer.
Ludo
cam.lafit@azerttyu.net a écrit :
S'lt
Si tu utilises un boucle complexe ou un plugin particulier la
connexion peut partir en carafe.
Pour savoir il essayer de determiner quelle page est à la source du
pb, sachant que dans ce cas spip.log et mysql.log seront de peu
d'utilité à priori.
En fait, je ne connais pas de pages de mon site qui soit rapide à charger.
Cela voudrait dire que l'ensemble des pages du plugin eva-web utilisent des boucles complexes??
Bonjour,
Olivier Gautier, développeur d'EVA-web.
Il n'y a pas grande complexité dans les boucles d'EVA. Et ce problème n'a jamais été signalé par les utilisateurs d'EVA jusqu'à présent.
Personnellement, je pencherais soit pour un problème côté hébergeur (comme l'indiquent les messages de mysql.log), soit côté plugin additionnel (mais ça n'a pas l'air d'être le cas).
Peut-on avoir l'adresse du site ?
Cordialement,
Olivier Gautier.
Merci de m'aider à avancer.
Ludo
cam.lafit@azerttyu.net a écrit :
S'lt
Si tu utilises un boucle complexe ou un plugin particulier la
connexion peut partir en carafe.
Pour savoir il essayer de determiner quelle page est à la source du
pb, sachant que dans ce cas spip.log et mysql.log seront de peu
d'utilité à priori.
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Il n'y a pas grande complexité dans les boucles d'EVA. Et ce problème n'a jamais été signalé par les utilisateurs d'EVA jusqu'à présent.
OK.
Personnellement, je pencherais soit pour un problème côté hébergeur (comme l'indiquent les messages de mysql.log),
Les admins APINC ont plutôt mis en cause l'application.
soit côté plugin additionnel (mais ça n'a pas l'air d'être le cas).
A voir quand même.
En plugins actifs j'ai:
- les plugins d'evaweb
- accès restreint
- balise session
- cfg
- couteau suisse, avec d'activé:
- SPIP et le cache
- Type d'interface privée
- Format des URLs
- Belles puces
- crayon
- Effacer URL Propres
- expresso
- SpipBB
- Thickbox v2 (installé très récemment, bien après que ça rame autant)
Il n'y a pas grande complexité dans les boucles d'EVA. Et ce problème n'a jamais été signalé par les utilisateurs d'EVA jusqu'à présent.
OK.
Personnellement, je pencherais soit pour un problème côté hébergeur (comme l'indiquent les messages de mysql.log),
Les admins APINC ont plutôt mis en cause l'application.
soit côté plugin additionnel (mais ça n'a pas l'air d'être le cas).
A voir quand même.
En plugins actifs j'ai:
- les plugins d'evaweb
- accès restreint
- balise session
- cfg
- couteau suisse, avec d'activé:
- SPIP et le cache
- Type d'interface privée
- Format des URLs
- Belles puces
- crayon
- Effacer URL Propres
- expresso
- SpipBB
- Thickbox v2 (installé très récemment, bien après que ça rame autant)
C'est vrai que c'est trèèèèèèèèèssssssssss llllllllllooooonnnnnnnnggggggggggggg, jamais croisé sous EVA...
Pour trouver le coupable, 2 solutions :
- désactiver un à un les plugins, vider le cache et voir...
- désactiver tous les plugins, les réactiver un à un, vider le cache et voir...
Merci du coup de main en tous cas.
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Avant:
J'avais des logs mysql douteux du style "Sep 09 02:30:13 65.55.208.251 (pid 5151) 2006 MySQL server has gone away" dans /tmp/mysql.log .
Côté serveur mysql, ben ... il tournait et tourne toujours bien.
Par contre, mes pages étaient hyper hyper lentes à charger, y compris côté backend.
J'avais les plugins suivant d'installé:
- les plugins d'evaweb
- accès restreint
- balise session
- cfg
- couteau suisse, avec d'activé:
- SPIP et le cache
- Type d'interface privée
- Format des URLs
- Belles puces
- crayon
- Effacer URL Propres
- expresso
- SpipBB
- Thickbox v2 (installé très récemment, bien après que ça rame autant)
Sur les conseils d'Olivier Gautier, j'ai désinstallé pas mal de plugins (mais j'ai été moins méthodique que ce qu'il me conseillait).
Après:
J'ai toujours des logs mysql douteux avec des "2006 MySQL server has gone away" réguliers, mais la vitesse du site s'est fortement améliorée (sans pour autant être satisfaisant) depuis la désinstallation des plugins suivant:
- accès restreint
- balise session
- cfg
- crayon
- Effacer URL Propres
- SpipBB
- Les plugins spécifiques d'evaweb dont je ne me sers pas (jclic, géo, evafreemind etc ...)
J'administre un autre site SPIP sur la même plateforme, mais pas avec le même squelette, et j'ai aussi les mêmes logs mysql douteux.
Avant:
J'avais des logs mysql douteux du style "Sep 09 02:30:13 65.55.208.251 (pid 5151) 2006 MySQL server has gone away" dans /tmp/mysql.log .
Côté serveur mysql, ben ... il tournait et tourne toujours bien.
Par contre, mes pages étaient hyper hyper lentes à charger, y compris côté backend.
J'avais les plugins suivant d'installé:
- les plugins d'evaweb
- accès restreint
- balise session
- cfg
- couteau suisse, avec d'activé:
- SPIP et le cache
- Type d'interface privée
- Format des URLs
- Belles puces
- crayon
- Effacer URL Propres
- expresso
- SpipBB
- Thickbox v2 (installé très récemment, bien après que ça rame autant)
Sur les conseils d'Olivier Gautier, j'ai désinstallé pas mal de plugins (mais j'ai été moins méthodique que ce qu'il me conseillait).
Après:
J'ai toujours des logs mysql douteux avec des "2006 MySQL server has gone away" réguliers, mais la vitesse du site s'est fortement améliorée (sans pour autant être satisfaisant) depuis la désinstallation des plugins suivant:
- accès restreint
- balise session
- cfg
- crayon
- Effacer URL Propres
- SpipBB
- Les plugins spécifiques d'evaweb dont je ne me sers pas (jclic, géo, evafreemind etc ...)
J'administre un autre site SPIP sur la même plateforme, mais pas avec le même squelette, et j'ai aussi les mêmes logs mysql douteux.
Vous croyez que ça vient de SPIP???
Merci de vos réponses et à bientôt.
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Si un autre SPIP au même endroit te fait la même, ca peut venir quand même du serveur MySQL
Pas d'après les admin de l'APINC.
D'après l'un d'eux, ça se passe comme ça:
(12:51:25) mat: - ouvrir connection mysql
(12:51:32) mat: - faire des opérations diverses qui prennent du temps
(12:51:36) mat: - faire une requete sql
(12:51:54) mat: ce dernier truc échoue parceque les opérations diverses en 2 ont pris trop de temps
(12:52:55) mat: le problème est double ici
(12:53:18) mat: ce comportement, si ca arrive c'est parceque on a un timeout assez bas au bout duquel mysql décide que il faut fermer la connection
(12:53:34) mat: mais si on l'augmente trop, on risque de saturer le serveur de connections qui ne font rien
Sous quelle solution? Mutualisé? Dédié?
Vérifie auprès de l'hébergeur la bonne santé du serveur
-----Message d'origine-----
De : spip-bounces@rezo.net [mailto:spip-bounces@rezo.net] De la part de
Ludovic CHEVALIER
Envoyé : jeudi 16 octobre 2008 13:21
À : spip@rezo.net
Objet : Re: [Spip] Logs mysql douteux
Re!
Je suis chez APINC.
Samy RABIH a écrit :
Si un autre SPIP au même endroit te fait la même, ca peut venir quand
même du serveur MySQL
Pas d'après les admin de l'APINC.
D'après l'un d'eux, ça se passe comme ça:
(12:51:25) mat: - ouvrir connection mysql
(12:51:32) mat: - faire des opérations diverses qui prennent du temps
(12:51:36) mat: - faire une requete sql
(12:51:54) mat: ce dernier truc échoue parceque les opérations
diverses en 2 ont pris trop de temps
(12:52:55) mat: le problème est double ici
(12:53:18) mat: ce comportement, si ca arrive c'est parceque on a un
timeout assez bas au bout duquel mysql décide que il faut fermer la
connection
(12:53:34) mat: mais si on l'augmente trop, on risque de saturer le
serveur de connections qui ne font rien
Voilà. Je continue donc le ping-pong.
Merci pour ta réponse.
Ludo
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Si un autre SPIP au même endroit te fait la même, ca peut venir quand même du serveur MySQL
Pas d'après les admin de l'APINC.
mouais, mais la première reponse d'un hebergeur est toujours : ca doit venir de votre script.
Il faut carrement insister pour engager un vrai dialogue...
Il faut aussi comprendre que spip "protege" la base de données, ce qui rend le probleme difficilement visible.
quand il y a un probleme de connexion à la base, spip cesse d'essayer les connexions pendant 2mn (spip 2.0 c'est 30s).
Du coup, dans les logs de MySQL, il n'y a qu'un echec.
la visiblement, la connexion se fait bien, mais ca part en cacahouete entre l'envoi de la query et la reception du resultset.
ce qu'il faut voir, c'est si ca tombe toujours sur le meme genre de requete ou si ca arrive n'importe quand.
Tu peux aussi essayer de mettre dans ton mes_options :
$GLOBALS['mysql_rappel_connexion'] = true;
ca peut etre le temps d'execution mysql trop court par rapport au temps d'execution PHP.
sinon, c'est plutot symptomatique d'une surcharge du serveur mysql...
il faut envoyer l'heure precise avec le PID (la ligne premiere ligne ou il y a l'erreur dans spip_log, qui doit etre à la meme date/heure que le fichier mysql_out) à l'hebergeur pour qu'il puisse trouver qqchose dans ses logs.