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/
