Bonjour,

(J'ai hésité à poster ce message ici, en Hébergement de Sites ou plutôt en forum SQL. Mais le problème me semble plus lié à l'hébergement en fait. Si un modérateur estime que je me suis trompé de section, qu'il déplace à sa guise ! )

Mon serveur MySQL est parfois inaccessible, sans aucune raison apparente (pas de plantage, le nombre de connectés simultanés n'est pas atteint, rien...).

Pas d'indication d'erreur non plus, à part ce "(4)" dont je ne comprends pas la signification :



Le serveur MySQL est distant et habituellement il n'y a pas de problème. Si un visiteur rencontre cette erreur, il lui suffit d'actualiser pour qu'en général, la page se charge. Mais c'est assez curieux quand même.

Serait-ce possible que ce soit dû à des pertes de paquets entre les serveurs OVH (je possède un serveur pour apache et un serveur pour MySQL) ? On a effectivement pas mal de requêtes SQL (850 requêtes SQL / secondes pour être exact) mais le "bug" ne touche qu'une minorité.

Merci pour vos réponses

Hello,

je viens de regarder sur une de mes machines qui rencontre fréquement ce soucis :


J'ai le même 4... et dans mon cas il s'agit du timeout MySQL (configuré à 20 secondes sur le serveur web utilisant cette machine).

Je n'irais pas jusqu'à dire que tu as le même soucis, mais si c'est le cas il s'agirait de pertes de paquets.... maintenant la cause peut venir d'un problème matériel, d'un filtre sur un switch, d'un vol d'IP (déjà rencontré ), d'un filtre au niveau du kernel (ip_conntrack), d'un bug des drivers, ou sûrement encore autre chose

Je vais essayer de voir à quoi correspond ce "4" ; mais s'il s'agit du code erreur, perror le traduit par "Interrupted system call" ce qui pourrait correspondre au timeout :S


PS : s'il s'agit de ton code perso, je te suggère d'auditer un peu les connexions. Pour ma part je trace toutes les connexions qui durent plus de 500ms à s'établir, et je me retrouve régulièrement avec des vagues de connexions "lentes".

OK, merci beaucoup pour ta réponse !

Je vais commencer par voir du côté du timeout, ça me semble être une solution plausible Je te tiens au courant.

J'ai mesuré le temps de chargement des pages qui entraînaient une erreur de connexion MySQL et c'est exactement ça : elles chargent toutes pile 60 secondes avant de provoquer une erreur ! Et même chose que pour toi, elles apparaissent par vagues.

Aujourd'hui à 12:50, j'ai eu 130 connexions lentes (temps de chargement de 60 secondes) qui ont entraîné un timeout de MySQL puis.... Plus rien. Puis d'erreur. 130 erreurs d'un coup et plus rien.

Ce qui est curieux c'est que ces connexions ne sont pas répertoriées comme tentatives échouées par MySQL (du moins par phpMyAdmin). J'en déduis donc qu'en fait, la connexion au serveur MySQL ne se fait même pas (ce que je veux dire, c'est que le serveur Apache ne se connecte même pas à l'IP du serveur MySQL). Qu'en penses-tu ?

Je sais pas trop par où commencer. D'après toi ça viendrait de perte de paquets ? Ce qui est bizarre c'est que quand je regarde mon graph MRTG (via le manager OVH), j'ai 0 erreurs... A moins que ça n'ait rien à voir ?

Je vais essayer de toucher un peu au serveur apache, je te tiendrais au courant...

De ton côté tu as toujours l'erreur ou tu as sûr la résoudre ?

Ce n'est donc pas exactement le même soucis que moi : dans mon cas les pertes de paquets se traduisent par une latence de 3 secondes lors de la connexion au serveur MySQL. Quand il y a beaucoup de pertes, cela passe à 9 secondes, puis 27 secondes.
Afin que nos pages soit malgré tout affichées, dans la conf PHP on a baissé le timeout de MySQL à 20 secondes... et on a donc souvent l'erreur "can't connect" comme tu indiques ; mais le cas le plus fréquent est la latence de 3 secondes.
On a ce soucis depuis plusieurs mois, nous avons tenté plein de modifications hardware et software (avec l'aide de l'hébergeur et rien y fait).

Mais je ne suis pas certain que tu ais exactement le même soucis (et je ne te le souhaite pas ) : te connectes tu via l'adresse IP de la machine ou via un nom d'hôte ? D'après ton message d'erreur j'aurais tendance à dire via l'IP mais dans le doute...

Enfin pour moi un serveur MySQL qui ne répond pas à la connexion TCP sous 30 ou 60 secondes, c'est qu'il y a un soucis coté réseau... ce qui implique aussi le firewall par exemple. Vu ton nombre de requetes par seconde, il se peut que le "connection tracking" d'une des machines sature... ou encore un soucis coté "syn cookies" si ceux ci sont activés.

Sinon il semblerait que tu ne sois pas le seul à te plaindre de soucis réseau chez OVH ces derniers temps ; c'est peut être lié.

Je me connecte au serveur MySQL directement sur l'IP Et oui, ce n'est pas le même problème... Juste le même message d'erreur.

J'ai fait encore pas mal de tests et finalement je m'oriente moi aussi vers l'hypothèse d'un problème réseau. J'ai contacté OVH mais entre temps, j'ai fait mes petits tests / pings, et voilà :

Résultat d'un ping constant toutes les secondes pendant une heure environ, de mon serveur Apache à mon serveur MySQL (de 8h15 à 9h15) :



Et en regardant mes logs d'erreurs persos j'apprends que la connexion à MySQL était impossible entre 8:29:41 et 8:30:08, soit pendant 27 secondes... Laps de temps au cours duquel 104 connexions ont été refusées.

Je sais vraiment plus du tout quoi y penser... o_O

L'erreur Interrupted System Call (4) n'apparaît que si la connexion est impossible, non ? Si la connexion avait été interrompue, il y aurait eu une erreur du genre "Lost connection to MySQL server during query", non ? J

J'espère vraiment qu'OVH trouvera un problème matériel :s, sinon je sais vraiment pas comment je vais résoudre ça~~

(A un moment dans ton message tu parles de connection tracking et j'ai pas trop saisis :/ Tu pourrais m'éclaircir là dessus ? J'ai fait des recherches sur Google mais rien de concluant...)

En fait le "firewall" Linux (netfilter) utilisent diverses méthodes dont le "suivi de connexion". Et pour gérer ce suivi de connexion il utilise une "table" qui est limitée en taille : si elle sature, toutes les nouvelles connexions sont "dropées", ce qui peut se traduire par un timeout lors de l'ouverture de socket TCP.

Bonjour,

Je rencontre moi aussi actuellement le problème sur déjà plusieurs serveurs. J'ai donc fait pas mal de recherches dans ce sens, et il semblerais que le connection tracking soit à exclure: lorsque la table sature, des messages sont visible dans le syslog ou le logbuffer du kernel. D'autre part, j'ai pour ma part jamais atteint cette limite entre un serveur web et MySQL.

Le problème ne semble pas non plus venir du réseau, étant donné que ceci à l'air de se produire aussi sur des serveurs OVH et que mon réseau est intégralement en Gigabit et sans aucun autre problème.

Un thread en anglais parlant de ce problème, et avec mon explication se trouve ici:
LinuxQuestions.org

Il semblerais qu'activer l'IPv6 dans le kernel résolve le problème, ce que je suis actuellement en train de tester. Ensuite reste à trouver en quoi activer l'IPv6 résoud ce genre de chose.

J'essaye donc actuellement de trouver quels seraient les points communs entre les serveurs qui posent problèmes, et de récolter un maximum d'informations à ce sujet. Si vous avez des infos, n'hésitez pas à m'envoyer tout ca en privé.

Merci :)

Fuzzy : regarde le pseudo de l'auteur sur le forum que tu indiques

En tous cas pour moi l'IPv6 n'a réglé le soucis que durant quelques jours... ce fut une "trève" sympathique, mais le soucis n'est toujours pas réglé.

J'ai vu, c'est pour ca que j'ai cru utile de faire le lien ici


Bon à savoir. Comment gères tu donc le problème actuellement ? C'est de mon côté quelque chose d'assez critique qui gène énormément d'autant plus quand les appels de scripts sont générés par une animation Flash.

J'ai repéré un problème qui à été corrigé très récemment, on va voir si cela arrange les choses.

Depuis peu en fait on règle le timeout mysql assez bas, et on gère un vrai timeout coté PHP : c'est pas propre, mais au moins on arrive généralement à initialiser la connexion mysql dans un délai correct.

Le problème avec ca, c'est qu'en réglant un timeout sur MySQL on fait échouer la connexion dès que le problème arrive. Ca veut dire qu'il faut forcément prendre en compte cela directement dans son code PHP. Ce n'est pas tout le temps possible, particulierement quand le code n'est pas le sien . De plus, tu auras toujours le délai de 3 secondes, celui ci venant du syscall connect(), tu ne peux pas , par définition l'interrompre ou le changer. La connexion durera donc 3 secondes, échouera, et sera réssayée. Je pense qu'a ce moment la il vaut mieux laisser connect() faire son boulot et immédiatement donner accès à la connexion après 3 secondes.

Les changements introduits dans les nouveaux kernels n'arrangent pas les choses, ni le problème. Pour l'instant le seul truc utilisable que j'ai est un 2.6.20.7 qui à l'air de fonctionner sans erreur. Je vais après compiler tous les kernels suivants un par un jusqu'a ce que je tombe sur le bug, et ensuite il faudra bisect. Rien que la quantité de boulot que cela implique me déprime un peu. Il n'empeche que je suis surpris qu'un truc pareil n'ait pas fait surface plus tôt et ne soit pas plus "populaire", surtout si cela apparait dans des configs multiserveur avec par exemple des serveurs OVH (a moins qu'il y ait vraiment peu de monde a faire du multiserveur?). En même temps, cela ne dérange pas tout le monde qu'une page de temps en temps soit plus lente à charger (c'est beaucoup, beaucoup plus dérangeant quand il s'agit d'interactions avec flash)

A suivre après ces tests

Kioob: est ce que tu utilises toujours le module conntrack dans ton kernel? Si oui, est ce qu'il te serait possible de voir si le problème se produit en le supprimant complètement? Afin de reproduire le bug de mon côté, je ne peux pas , pour ma part enlever ce module (c'est un composant clé dans mon système). C'est prévu qu'il dégage bientôt, mais c'est encore trop de boulot et de tests entre maintenant et ce "bientôt".

J'ai balancé le problème et attiré l'attention de gens du côté du dévelopement de la partie réseau du kernel, et c'est vrai que la un des points qui bloque c'est de savoir si conntrack y serait pour quelque chose ou non.

Sinon tu aurais des infos sur les specs hardware de tes serveurs qui posent problème ? notamment l'archi (32 ou 64-bit), la plateforme (intel ou amd), et bien sûr le controleur réseau?

Si tu es partant, fais moi signe

Que ça vienne de syscall ou non n'y change rien en tous cas : cette méthode fonctionne relativement bien, on a réduit le temps moyen de connexion durant ces "vagues" de pertes, et nous n'avons plus de connexions complètement perdues (le timeout d'origine était à 20 secondes).

Sinon pour le fait que peu de gens n'ait remonté le problème, pour moi ça vient aussi du fait que peu de gens auditent leur code à mon avis

La désactivation d'ipconntrack serait possible, mais je n'ai plus vraiment de temps à y consacrer : j'ai perdu un temps fou là dessus, et mon taff doit quand même être fait. Donc recompiler un kernel sur les 3 machines de prod, puis désactiver temporairement le firewall ; je ne suis pas trop motivé dsl.

Sinon les 3 machines sont en 64bits, ce sont des Xeon d'ancienne génération (basés sur netburst) avec des cartes Intel.
Sur les serveurs Web comme le serveur MySQL :

Nous avons testé les deux interfaces, la première en 10Mbit/s FD et la deuxième en 100Mbit/s FD.

Et n'ayant aucun client avec un code "propre" et centralisé, pas moyen d'auditer sur d'autres machines.