Bonjour, Le problème me fait penser à un pb similaire que j'ai eu il y a déjà pas mal de temps, mais qui ressemble un peu à celui là. J'avais des gros lags sur une interface réseau aléatoirement sur certains services tcp/ip, la solution a été de changer l'interface réseau .. radicale mais ça a marché. Il s'agissait d'après quelques infos sur le net d'une instabilité du chip gigabit sur certains OS... A ta place j'essaierai de mettre une simple carte 10/100 avec les même config pour tester ...
Bon courage .. Brice VINCENT. 2008/3/4 Gabriel Barazer <[EMAIL PROTECTED]>: On 03/04/2008 12:19:27 AM +0100, "Christophe VIAUD" > <[EMAIL PROTECTED]> wrote: > > >> - coté flux: > >> - aucun équipement de filtrage à ce niveau > >> les autres équipements n'interagissent pas avec les 3 serveurs en > >> question, et fonctionnent d'eux même très bien. > >> - Lorsque le problème survient, comme j'avais tenté de l'expliquer, > >> c'est uniquement les connexions entre un serveur web et le serveur > mysql > >> qui font ce "bégaiement" TCP. toutes les autres communications > entrantes > >> et sortantes du serveur web et mysql fonctionnent (ssh sur les 2 > >> serveurs, le http qui marche sur le web sans problème, mysql qui > >> fonctionne sans problème avec l'autre serveur). > >> > > Le fait que tu sois en ssh ne prouve pas le fait qu'il n'y ait pas de pb > > de cnx. ça m'arrive de perdre ma cnx wifi et pourtant ma cnx ssh > > refonctionne souvent le temps que le wifi revienne (parfois ok ça > > déconnecte :) ) > > le mieux c'est de faire un ping TCP à partir de tes serveurs web à > > destination de ton serveur MySQL, avec hping par exemple : > > hping3 [ip] -p 3306 -S > > Quand je parle de connexion SSH, je ne parle pas d'idler sur une > session, je parle de faire mes tests a partir de la session SSH en > question, donc non je suis sur qu'il n'y a aucun problème dessus :) > > Pour tester le TCP, et n'ayant rien d'autre sous la main a ce moment la, > j'ai utilisé telnet <ip> 3306 . Même effet, même résultat négatif. > > > > >> - la table arp n'a pas plus de 10 entrées et je controle le réseau > local > >> de bout en bout, donc pas de connexion sauvage ou de conflit d'IP. > >> > > Ne le prend pas mal, tu l'as sûrement fait mais une re-vérif des > configs, > > c'est possible ? (ça arrive à tout le monde et le plus souvent plus > c'est > > gros et moins on le voit :) ) > > J'ai bien sur revérifié tout ca. En fait c'est plutot simple puisque > j'ai simplement à jeter un coup d'oeil dans une interface et a cliquer > :). J'ai aussi vérifié manuellement sur chaque serveur (ca va encore le > pool est petit) > > > d'autant plus que c'est une nouvelle install,... (une piste est une > piste > > c'est tjrs ça de pris) > > Nouvelle install mais même architecture que plusieurs déjà existantes, > c'est ca que j'arrive pas à m'expliquer, et qui me fait penser que le > problème est lié au réseau ou a une bizarerie de ce genre plutôt qu'a un > problème applicatif (pour lequel j'ai tout vérifié) > > > > >> N'ayant aucune piste, j'ai déjà vérifié tous ces élements jusqu'au > trucs > >> les plus absurdes sans rien trouver. > >> > >> J'ajoute que lorsque le problème arrive, un netstat sur le serveur > MySQL > >> montre tout un tas de connexions venant du serveur web en état > >> "SYN_RECV" prouvant bien que le serveur est en train d'attendre que le > >> client accepte la connexion. Le client de son côté a envoyé le SYN > >> initial, recu le ACK du serveur, mais au lieu de répondre, il attend 3 > >> secondes et retransmet le SYN. Simultanément, le meme serveur accepte > >> les connexions de l'autre serveur web sans broncher. > >> > > c'est quoi qui fait les cnx vers le MySQL : du php ? python ? perl ? > > avec le ping tcp (hping), tu devrais voir des pb de cnx en même temps > que > > ton pb. Dans le cas où que le ping TCP ne pose pas de pb, mais que ton > > serv web a du mal à se connecter, il faudra regarder la partie > logicielle > > (config, voir avec les developpeurs de l'appli ...) > > du PHP, mais ce n'est pas ce qui pose le problème. Et les problèmes de > connexion sont effectivement visible en même temps. Mes captures > indiquant la retransmission TCP qui n'a pas lieu d'être de la part du > client prouve que le problème est "dessous" l'applicatif. Mais je ne > suis pas un fainéant, j'ai juste déjà passé 36h sur les points dont tu > parles :) > > > > > 400 req/s : il y a du cache ou à chaque fois tu as des cnx vers le MySQL > ? > > pour voir s'il faut travailler du côté des descripteurs de socket. > > Pour 400 requetes, on peut compter environ 200 connexions effectives au > serveur MySQL (200 sessions TCP quoi). Aucun problème de sockets, pas de > problème de backlog trop court. D'autre part, le serveur à côté fait > dans les 1500 connexions par seconde sans broncher sur _exactement_ la > même configuration matérielle et logicielle. > > J'ai eu le problème à l'instant, et j'ai réussi a raccourcir le temps > d'indisponibilité de 1 minute a environ 20 secondes (mais c'est loin > d'être suffisant étant donné le caractère critique du temps de réponse). > J'ai tout simplement, et dans le non-respect des standards, raccourci le > temps avant le retry d'une retransmission TCP à une seconde au lieu de > 3. (echo 1 > /proc/sys/net/ipv4/tcp_retries1). C'est tout ce qu'il y a > de plus dégeu, mais cela ajoute à l'hypothèse qu'il s'agit bien d'un > ennui au niveau réseau. > > Je vais voir du coté de hping ce que ca peut m'apporter comme infos en > plus, mais ayant déjà un trace pcap du problème, je vois mal ce que je > peux obtenir de plus. (et je ne peux pas poster ces traces, étant donné > qu'ils contiennent les packets d'authentification de Mysql... mais je > vais essayer d'en faire une version "publique"). En simplifié: > T=0s.0000 : client:xyz > serveur:3306 TCP SYN > T=0s.0001 : serveur:3306 > client:xyz TCP SYN, ACK > T=3s.0000 : client:xyz > serveur:3306 TCP SYN > T=3s.0001 : serveur:3306 > client:xyz TCP SYN, ACK > T=3s.0002 : client:xyz > serveur:3306 TCP ACK > T=3s.0003 : serveur:3306 > client:xyz MySQL (début de la converstation) > > Gabriel > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > >
