Fuzzy

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

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

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.

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