Bonjour les devs,
On a farfouillé dans nos logs pour expliquer des "sites en travaux" incessants
sur notre SPIP 2.1.2, et on a trouvé ça dans spip.log, qui revient régulièrement
:
Dec 20 16:07:26 10.1.2.44 (pid 4189) spip_connect: serveur 0 mal defini dans
'config/connect.php'.
Est-ce que ça dit quelque chose à quelqu'un ?
Chez quel hebergeur es-tu?
J'ai eu ce souci chez OVH, depuis que j'ai changé de contrat, plus de
problème
JPP
-----Message d'origine-----
Envoyé : mardi 21 décembre 2010 12:01
dans'config/connect.php'.
Bonjour les devs,
On a farfouillé dans nos logs pour expliquer des "sites en travaux"
incessants sur notre SPIP 2.1.2, et on a trouvé ça dans spip.log, qui
revient régulièrement
:
Dec 20 16:07:26 10.1.2.44 (pid 4189) spip_connect: serveur 0 mal defini dans
'config/connect.php'.
Est-ce que ça dit quelque chose à quelqu'un ?
On est chez Nexen Alterway Hosting.
Tu as changé de contrat, c'est-à-dire d'hébergeur ? Ou bien est-ce qu'OVH a
trouvé une solution ? et laquelle ?
Suis resté chez OVH
J'avais un forfait 60gp qui d'après OVH était trop faible par rapport au
nombre de visite journalières du site.
Suis passé au forfait 90Plan, il y a 2 ans, toujours chez OVH, et plus de
souci
JPP
-----Message d'origine-----
Envoyé : mardi 21 décembre 2010 12:43
Salut JP,
OK, donc plutôt une histoire de bande passante...
Curieux...
Nous on a augmenté le nombre de connexions simultanés, on est arrivé à un
chiffre faramineux, on en utilise même pas le quart, et pourtant, les pbs
continuent. On va creuser du côté de la bande passante, donc...
Merci !!
Bonjour,
sur un 90Plan j'avais aussi ce problème.
Mais les sites ont toujours bien fonctionnés, alors avec le temps j'ai
oublié.
A bientôt
Grégoire
Bonjour les devs,
On a farfouillé dans nos logs pour expliquer des "sites en travaux" incessants
sur notre SPIP 2.1.2,
"sites en travaux" c'est un problème de disponibilité du serveur mysql qui tombe ou ne répond pas.
et on a trouvé ça dans spip.log, qui revient régulièrement
:Dec 20 16:07:26 10.1.2.44 (pid 4189) spip_connect: serveur 0 mal defini dans
'config/connect.php'.Est-ce que ça dit quelque chose à quelqu'un ?
C'est juste une conséquence.
Quand SPIP n'arrive pas à joindre le serveur SQL, il pose un fichier tmp/mysql_out.
Ensuite tous les hits qui veulent se connecter à SQL regardent d'abord si ce fichier existe,
et si il date de moins de 30s, ils rendent la main sans ouvrir de connexion. Consécutivement,
SPIP génère ce log trompeur car il croit que le fichier de connexion est mal défini alors que
l'erreur provient du serveur SQL indisponible.
Le créneau de 30s permet de soulager le serveur SQL pour lui permettre de se rétablir.
Mais si ton SPIP est régulièrement en caraffe à cause de SQL alors :
- soit ton SQL est sous dimensionné
- soit il est sur un serveur séparé, et ta connexion avec le serveur est engorgée/instable...
Un sous dimensionnement éventuel peut être la conséquence de squelettes ou plugin
qui ne respectent pas l'utilisation du cache et sollicitent SQL à chaque hit.
Cédric
Merci Cedric pour ce point,
Justement, nous sommes sur des serveurs séparés.
Plus précisément, 4 frontaux en round robin pour le service des pages web, et un
serveur de BDD.
Ce que tu dis semble signifier que SPIP peut difficilement fonctionner sur des
config ou web / bdd sont dissociés ?
Quelles précos pour pouvior fonctionner normalement sur une architecture de ce
type, en terme de liens serveurs web / bdd ? (Nous avions déjà commencé par
augmenter le nb de connexions simultanés à MySQL à 1024, et utilisons cette
capacité de connexions au quart. Donc ce n'est pas ça...
Merci !
Bonne soirée
Z
Selon "cedric.morin@yterium.com" <cedric.morin@yterium.com>:
Bonjour les dev,
La suite sur le pb des messages "site en travaux" avec "serveur mal défini" dans
spip.log (on a 2.1.2).
Aujourd'hui, notre hébergeur est pratiquement sûr que ce pb ne met pas en cause
son architecture (4 frontaux web en round robin connectés à 1 serveur de BDD) +
caches Varnish, firewall et mode security Apache), d'après les erreurs qu'il
voit dans les logs, plus explicites.
Ce pb serait "purement applicatif" (donc spip) qui aurait tendance à inventer
des users mysql qui n'existent pas :
Est-ce que vous avez déjà rencontré ça ?
Jan 03 17:13:02 10.1.2.41 (pid 5374) Erreur 1449 de mysql: The user specified as
a definer ('manager'@'%') does not existINSERT INTO spip_documents_liens
(id_document,id_objet,objet) VALUES (113293,20190,'article')
INSERT INTO spip_documents_liens (id_document,id_objet,objet) VALUES
(113293,20190,'article')
+ une autre qui dit que la table article n'existe pas.
+ encore une floppée de
Dec 30 11:07:34 10.1.2.42 (pid 26404) Echec connexion mysql meeddatrefonte
meeddatrefonte
Dec 30 11:07:42 10.1.2.42 (pid 26315) Echec connexion mysql meeddatrefonte
meeddatrefonte
Dec 30 11:07:43 10.1.2.43 (pid 26422) Echec connexion mysql meeddatrefonte
meeddatrefonte
(meeddatrefonte = notre BDD)
Pour le reste, aucune coupure réseau
Aucun dysfonctionnement constaté coté architecture.
Les tests effectués en passant outre firewall, cache et apache2 mod_sec remonte
la même erreur (site en travaux) en modifiant les fichiers de configs.
Les bases de données ne présentent pas de baisse de trafic non plus.
SPIP aurait-il des difficultés à générer des requêtes SQL dans certains cas de
figure ?
Une expertise serait souhaitable, mais en attendant, quelqu'un aurait une idée
sur ces messages ?