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/
