[FRnOG] Re: [FRnOG] problème/enigme TCP qui bégaye
Salut, Tes deux serveurs fonctionne en solo ou il y a une notion de cluster ? Dans les logs du serveurs au rais tu des erreurs ? Un autre truc tout bete tes ports de switchs sont en auto ou configure ? Tes cartes sont en auto ou en full ? Qu' a tu sur tes autres ports ? As tu des pare feu sur tes serveurs ? As tu fais un chagement de conf sur tes serveurs ? Serge CARPENTIER Squale Systems Ingenieur Télécom Réseau dCAP : DIGIUM Certified Asterisk Professional --- [EMAIL PROTECTED] Support : +33 825 627 431 Tel : +33 674886017 Tel : +33 659455493 --- Powered by BlackBerry Zimbra -Original Message- From: Gabriel Barazer [EMAIL PROTECTED] Date: Mon, 03 Mar 2008 23:38:25 To:Christophe VIAUD [EMAIL PROTECTED] Cc:frnog@frnog.org Subject: Re: [FRnOG] problème/enigme TCP qui bég aye Salut, Alors c'est simple, dans le sens premier du terme: - effectivement les 3 serveurs sur le même switch - pas de vlan taggé, un seul global untag - pas sur le switch en question - 1 lien par serveur vers le switch (3 liens total sur un switch qui en a actuellement une quinzaine) - aucune techno software style aggregation ni HA - c'est un nouveau déploiement, mais qui fonctionne sans problèmes sur quelques autres installations du même type (web + mysql) - j'ai le problème depuis 3 jours, et c'est suite à une migration depuis une ancienne infrastructure (qui commencait à montrer des symptomes similaires, je n'ai malheuresement pas pu tester ni faire de captures sur cette ancienne installation) - 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). - 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. 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. Je n'ai par ailleurs trouvé aucun élement ou serveur qui pourrait expliquer ce déclenchement du problème à intervalles si réguliers. J'avoue que c'est le genre de problème interessant à comprendre mais ca serait bien plus agréable si on me foutait pas autant la pression pour que ca marche derrière :) Gabriel On 03/03/2008 11:17:11 PM +0100, Christophe VIAUD [EMAIL PROTECTED] wrote: Salut, Je ne sais pas si ça intéresse tout le monde de suivre cette discussion, si cela gêne du monde, merci de nous le faire savoir on continuera en offline :D Pour ton pb, difficile d'en faire l'analyse sans qques infos complémentaires (pour ne rien perdre au passage et afin que l'on soit au même niveau d'info que toi ^_^) Côté architecture : - Ton architecture réseau c'est bien les 2 serveurs web et le serveur mysql sur le même switch ? - dans le même vlan ? - du spanning-tree ? - question bête mais sais t'on jamais : ton serveur MySQL a combien de lien physique vers ce switch ? fais-tu du teaming, channel bonding ou tout autre techno d'aggrégation de lien ou de tolérance de panne (lan ha,...) ? - lié à la question précédente : c'est un nouveau déploiement ? depuis combien de temps que tu as le pb par rapport à la date de déploiement ? Côté flux : - Pour ce flux tu passes en direct ou par un équipement de filtrage ? - quels sont les autres équipements (serveurs compris) qui sont dans le même segment que ton serveur et qui potentiellement pourrait nuir au trafic ? - lorsque le pb survient, c'est juste le flux serveur web - MySQL qui pose pb ou tu as des pb de connexion vers les serveurs web aussi ? as-tu vérifié les tables arp de tes serveurs web et de ton serveur MySQL lorsque le pb survient ? = je pense à une machine qui a la même ip ou la même adresse mac et qui pourrait émettre des trames de temps en temps, provoquant un pb dans la table de forwarding du switch, le temps de la ré-émission de paquet, ou encore un pb dans la config du teaming ou channel bonding (pb de mac flapping)... tu peux vérifier aussi dans
[FRnOG] problème/enigme TCP qui bégaye
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,
[FRnOG] problème/enigme TCP qui bégaye
Bonsoir, J'ai actuellement un problème qui m'est pour le moment totalement insoluble, et qui après 3 jours de farfouillage me permet de l'exposer clairement. Je sais qu'ici n'est pas un support technique, mais peut etre que certaines personnes ont déjà eu ce genre d'expérience alors je tente le coup :-) Problématique initiale: * j'ai 2 serveurs web qui interrogent un serveur MySQL (super original). Tout irait pour le mieux si *de temps en temps* l'un ou l'autre serveur web ne se mettait pas a faire la tronche au serveur MySQL et a ne plus vouloir se connecter. En fouillant, j'obtiens de droles de données qui commencent à me rendre dingue: - Cela se produit pile poil toutes les 15 minutes (un coup c'est un serveur, un coup c'est l'autre 15 minutes chacun en décalé) et dure à peine 1 minute - Lorsque cela se produit, le fait de telnet ip de mysql 3306 provoque une latence d'*exactement* 3 secondes avant d'afficher le welcome de mysql Après avoir cherché la ou ca ne donne rien, j'ai décidé de sortir tcpdump, et au moment ou ca arrive, de le lancer sur le serveur et le client en même temps (dans mon cas, un serveur web et un serveur mysql). La capture des paquets m'indique que le client envoie un SYN au serveur, qui répond par un SYN,ACK, puis 3 secondes précisément s'écoulent, et le client renvoie de nouveau un SYN, puis le serveur répond SYN,ACK, et enfin le client complète le 3-way handshake par un ACK (puis se met à causer le mysql). J'ai fait le rapprochement des 3 secondes d'attente avant retransmission avec la variable tcp_retries1 qui est le temps avant de ressayer une transmission TCP sous linux. La ou est l'énigme, c'est que la capture des paquets sur le client ET le serveur sont exactement les mêmes, il n'y a donc pas de paquet qui à été perdu en cours de route! Pourquoi cet idiot passe dans la procédure de retry en attendant 3 secondes plus tard ? Infos: Le switch est un bête truc D-Link gigabit, qui commute sans problème tout le reste du traffic, donc ce n'est pas la cause. MySQL ne semble pas être en cause, car pendant qu'il galère a communiquer avec un des 2 serveurs, l'autre continue ses conversations sans accroc. Ce n'est pas une histoire de charge car tout ce bazar ne dépasse pas les 0.3 même en crachant 400 requetes/seconde Le fond du problème est: depuis quand le protocole TCP bégaye-t-il ??? Et pourquoi toutes les 15 minutes ? Quelqu'un à déja vu un truc pareil ? A vôt bon coeur! Gabriel --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] problème/enigme TCP qui bégaye
On Mon, 03 Mar 2008 22:18:32 +0100, Gabriel Barazer [EMAIL PROTECTED] wrote: Bonsoir, Salut, J'ai actuellement un problème qui m'est pour le moment totalement insoluble, et qui après 3 jours de farfouillage me permet de l'exposer clairement. Je sais qu'ici n'est pas un support technique, mais peut etre que certaines personnes ont déjà eu ce genre d'expérience alors je tente le coup :-) Problématique initiale: * j'ai 2 serveurs web qui interrogent un serveur MySQL (super original). Tout irait pour le mieux si *de temps en temps* l'un ou l'autre serveur web ne se mettait pas a faire la tronche au serveur MySQL et a ne plus vouloir se connecter. En fouillant, j'obtiens de droles de données qui commencent à me rendre dingue: - Cela se produit pile poil toutes les 15 minutes (un coup c'est un serveur, un coup c'est l'autre 15 minutes chacun en décalé) et dure à peine 1 minute - Lorsque cela se produit, le fait de telnet ip de mysql 3306 provoque une latence d'*exactement* 3 secondes avant d'afficher le welcome de mysql Après avoir cherché la ou ca ne donne rien, j'ai décidé de sortir tcpdump, et au moment ou ca arrive, de le lancer sur le serveur et le client en même temps (dans mon cas, un serveur web et un serveur mysql). La capture des paquets m'indique que le client envoie un SYN au serveur, qui répond par un SYN,ACK, puis 3 secondes précisément s'écoulent, et le client renvoie de nouveau un SYN, puis le serveur répond SYN,ACK, et enfin le client complète le 3-way handshake par un ACK (puis se met à causer le mysql). J'ai fait le rapprochement des 3 secondes d'attente avant retransmission avec la variable tcp_retries1 qui est le temps avant de ressayer une transmission TCP sous linux. La ou est l'énigme, c'est que la capture des paquets sur le client ET le serveur sont exactement les mêmes, il n'y a donc pas de paquet qui à été perdu en cours de route! Pourquoi cet idiot passe dans la procédure de retry en attendant 3 secondes plus tard ? Infos: Le switch est un bête truc D-Link gigabit, qui commute sans problème tout le reste du traffic, donc ce n'est pas la cause. MySQL ne semble pas être en cause, car pendant qu'il galère a communiquer avec un des 2 serveurs, l'autre continue ses conversations sans accroc. Ce n'est pas une histoire de charge car tout ce bazar ne dépasse pas les 0.3 même en crachant 400 requetes/seconde Le fond du problème est: depuis quand le protocole TCP bégaye-t-il ??? Et pourquoi toutes les 15 minutes ? Quelqu'un à déja vu un truc pareil ? A vôt bon coeur! Gabriel J'ai eu exactement le problème il y a peu en testant une montée en charge de session sur des firewall. Au hasard, tu ne vois pas des trames spanning tree dans tes captures ? --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Steven Le Roux [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] problème/enigme TCP qui bégaye
On 03/03/2008 10:43:05 PM +0100, Steven Le Roux [EMAIL PROTECTED] wrote: On Mon, 03 Mar 2008 22:18:32 +0100, Gabriel Barazer [EMAIL PROTECTED] wrote: Bonsoir, Salut, J'ai actuellement un problème qui m'est pour le moment totalement insoluble, et qui après 3 jours de farfouillage me permet de l'exposer clairement. Je sais qu'ici n'est pas un support technique, mais peut etre que certaines personnes ont déjà eu ce genre d'expérience alors je tente le coup :-) Problématique initiale: * j'ai 2 serveurs web qui interrogent un serveur MySQL (super original). Tout irait pour le mieux si *de temps en temps* l'un ou l'autre serveur web ne se mettait pas a faire la tronche au serveur MySQL et a ne plus vouloir se connecter. En fouillant, j'obtiens de droles de données qui commencent à me rendre dingue: - Cela se produit pile poil toutes les 15 minutes (un coup c'est un serveur, un coup c'est l'autre 15 minutes chacun en décalé) et dure à peine 1 minute - Lorsque cela se produit, le fait de telnet ip de mysql 3306 provoque une latence d'*exactement* 3 secondes avant d'afficher le welcome de mysql Après avoir cherché la ou ca ne donne rien, j'ai décidé de sortir tcpdump, et au moment ou ca arrive, de le lancer sur le serveur et le client en même temps (dans mon cas, un serveur web et un serveur mysql). La capture des paquets m'indique que le client envoie un SYN au serveur, qui répond par un SYN,ACK, puis 3 secondes précisément s'écoulent, et le client renvoie de nouveau un SYN, puis le serveur répond SYN,ACK, et enfin le client complète le 3-way handshake par un ACK (puis se met à causer le mysql). J'ai fait le rapprochement des 3 secondes d'attente avant retransmission avec la variable tcp_retries1 qui est le temps avant de ressayer une transmission TCP sous linux. La ou est l'énigme, c'est que la capture des paquets sur le client ET le serveur sont exactement les mêmes, il n'y a donc pas de paquet qui à été perdu en cours de route! Pourquoi cet idiot passe dans la procédure de retry en attendant 3 secondes plus tard ? Infos: Le switch est un bête truc D-Link gigabit, qui commute sans problème tout le reste du traffic, donc ce n'est pas la cause. MySQL ne semble pas être en cause, car pendant qu'il galère a communiquer avec un des 2 serveurs, l'autre continue ses conversations sans accroc. Ce n'est pas une histoire de charge car tout ce bazar ne dépasse pas les 0.3 même en crachant 400 requetes/seconde Le fond du problème est: depuis quand le protocole TCP bégaye-t-il ??? Et pourquoi toutes les 15 minutes ? Quelqu'un à déja vu un truc pareil ? A vôt bon coeur! Gabriel J'ai eu exactement le problème il y a peu en testant une montée en charge de session sur des firewall. Au hasard, tu ne vois pas des trames spanning tree dans tes captures ? Pas dans mes captures directement (j'avais filtré) mais en recapturant sans filtrage j'ai effectivement du STP dans mes trames. En quoi cela pourrait jouer? Je n'ai pas compilé de support du 802.1d dans le noyau et c'est désactivé sur le switch D-link gigabit (c'est l'uplink qui envoie ces BPDU), il n'y a donc pas de raison que le switch se mette a bloquer des ports, d'autant plus que le serveur web, même si il est bloqué vers le serveur mysql avec cette latence due a la retransmission, continue de communiquer sans problème pour le contenu statique, et aussi ma session ssh dessus. Gabriel --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] problème/enigme TCP qui bégaye
Salut, Je ne sais pas si ça intéresse tout le monde de suivre cette discussion, si cela gêne du monde, merci de nous le faire savoir on continuera en offline :D Pour ton pb, difficile d'en faire l'analyse sans qques infos complémentaires (pour ne rien perdre au passage et afin que l'on soit au même niveau d'info que toi ^_^) Côté architecture : - Ton architecture réseau c'est bien les 2 serveurs web et le serveur mysql sur le même switch ? - dans le même vlan ? - du spanning-tree ? - question bête mais sais t'on jamais : ton serveur MySQL a combien de lien physique vers ce switch ? fais-tu du teaming, channel bonding ou tout autre techno d'aggrégation de lien ou de tolérance de panne (lan ha,...) ? - lié à la question précédente : c'est un nouveau déploiement ? depuis combien de temps que tu as le pb par rapport à la date de déploiement ? Côté flux : - Pour ce flux tu passes en direct ou par un équipement de filtrage ? - quels sont les autres équipements (serveurs compris) qui sont dans le même segment que ton serveur et qui potentiellement pourrait nuir au trafic ? - lorsque le pb survient, c'est juste le flux serveur web - MySQL qui pose pb ou tu as des pb de connexion vers les serveurs web aussi ? as-tu vérifié les tables arp de tes serveurs web et de ton serveur MySQL lorsque le pb survient ? = je pense à une machine qui a la même ip ou la même adresse mac et qui pourrait émettre des trames de temps en temps, provoquant un pb dans la table de forwarding du switch, le temps de la ré-émission de paquet, ou encore un pb dans la config du teaming ou channel bonding (pb de mac flapping)... tu peux vérifier aussi dans ta capture réseau, mais le mieux c'est qd le problème survient. voilà c'est déjà pas mal pour un premier diag :) t'as de quoi faire ;) -- Christophe VIAUD Bonsoir, J'ai actuellement un problème qui m'est pour le moment totalement insoluble, et qui après 3 jours de farfouillage me permet de l'exposer clairement. Je sais qu'ici n'est pas un support technique, mais peut etre que certaines personnes ont déjà eu ce genre d'expérience alors je tente le coup :-) Problématique initiale: * j'ai 2 serveurs web qui interrogent un serveur MySQL (super original). Tout irait pour le mieux si *de temps en temps* l'un ou l'autre serveur web ne se mettait pas a faire la tronche au serveur MySQL et a ne plus vouloir se connecter. En fouillant, j'obtiens de droles de données qui commencent à me rendre dingue: - Cela se produit pile poil toutes les 15 minutes (un coup c'est un serveur, un coup c'est l'autre 15 minutes chacun en décalé) et dure à peine 1 minute - Lorsque cela se produit, le fait de telnet ip de mysql 3306 provoque une latence d'*exactement* 3 secondes avant d'afficher le welcome de mysql Après avoir cherché la ou ca ne donne rien, j'ai décidé de sortir tcpdump, et au moment ou ca arrive, de le lancer sur le serveur et le client en même temps (dans mon cas, un serveur web et un serveur mysql). La capture des paquets m'indique que le client envoie un SYN au serveur, qui répond par un SYN,ACK, puis 3 secondes précisément s'écoulent, et le client renvoie de nouveau un SYN, puis le serveur répond SYN,ACK, et enfin le client complète le 3-way handshake par un ACK (puis se met à causer le mysql). J'ai fait le rapprochement des 3 secondes d'attente avant retransmission avec la variable tcp_retries1 qui est le temps avant de ressayer une transmission TCP sous linux. La ou est l'énigme, c'est que la capture des paquets sur le client ET le serveur sont exactement les mêmes, il n'y a donc pas de paquet qui à été perdu en cours de route! Pourquoi cet idiot passe dans la procédure de retry en attendant 3 secondes plus tard ? Infos: Le switch est un bête truc D-Link gigabit, qui commute sans problème tout le reste du traffic, donc ce n'est pas la cause. MySQL ne semble pas être en cause, car pendant qu'il galère a communiquer avec un des 2 serveurs, l'autre continue ses conversations sans accroc. Ce n'est pas une histoire de charge car tout ce bazar ne dépasse pas les 0.3 même en crachant 400 requetes/seconde Le fond du problème est: depuis quand le protocole TCP bégaye-t-il ??? Et pourquoi toutes les 15 minutes ? Quelqu'un à déja vu un truc pareil ? A vôt bon coeur! Gabriel --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] problème/enigme TCP qui bégaye
re, Salut, Alors c'est simple, dans le sens premier du terme: - effectivement les 3 serveurs sur le même switch - pas de vlan taggé, un seul global untag - pas sur le switch en question - 1 lien par serveur vers le switch (3 liens total sur un switch qui en a actuellement une quinzaine) - aucune techno software style aggregation ni HA - c'est un nouveau déploiement, mais qui fonctionne sans problèmes sur quelques autres installations du même type (web + mysql) - j'ai le problème depuis 3 jours, et c'est suite à une migration depuis une ancienne infrastructure (qui commencait à montrer des symptomes similaires, je n'ai malheuresement pas pu tester ni faire de captures sur cette ancienne installation) - 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 - 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 :) ) d'autant plus que c'est une nouvelle install,... (une piste est une piste c'est tjrs ça de pris) 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 ...) 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. Je n'ai par ailleurs trouvé aucun élement ou serveur qui pourrait expliquer ce déclenchement du problème à intervalles si réguliers. J'avoue que c'est le genre de problème interessant à comprendre mais ca serait bien plus agréable si on me foutait pas autant la pression pour que ca marche derrière :) comme d'habitude :) Gabriel -- Christophe VIAUD --- Liste de diffusion du FRnOG http://www.frnog.org/
