Le serveur est un serveur de base de données sous Debian/Sarge
Les clients sont des XP
Le switch 1 est un NetGear GSM7352S (48p/Gbit)
Le switch 2 est un Netgear FS750T2 (48p/100Mb)
Le serveur est connecté en Gb
Le client 1 aussi
Le lien entre les switchs et le lien du client 2 sont à 100Mb
Mon problème est le suivant :
Quand Client2 établit une connexion au serveur et commence à lire de
données, celles-ci partent plus vite du serveur que ce que le client
n'accepte (normal vu la diff de vitesse des liens).
Au bout d'un certain temps, la quantité émise par le serveur est telle que
le buffer du switch 2 explose et que la connexion TCP fait un slow
restart.
Le client 1 ne connait, quant à lui aucun pb de performance.
Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur
et/ou mes clients pour permettre de réguler le traffic sans aller
jusqu'au débordement de buffer (le slow restart plombe les performances).
Bien sûr, le cas présenté ici est isolé, dans la vraie vie j'ai plusieurs
serveurs et +++ clients.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Mathieu Goutelle
Bonsoir,
Dans l'article <473a0b82$0$25950$, Emmanuel a écrit :
Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur et/ou mes clients pour permettre de réguler le traffic sans aller jusqu'au débordement de buffer (le slow restart plombe les performances).
Sur un LAN, je doute que ce soit ça qui plombe les performances : compte tenu du délai d'aller-retour très court, la dynamique de TCP doit être très bonne. En plus, que vous fassiez de la limitation de débit au niveau du serveur ou dans le switch (parce que c'est ce qu'il se passe, hein), il y aura à un moment ou à un autre des paquets perdus et donc un TCP slow start.
Sincèrement, je pencherais plus pour un problème sur la machine cliente qui n'arrive pas à suivre... Pour s'en assurer, il suffirait de faire un test à la iperf entre serveur et client et vérifier que vous obtenez un très grosse part de 100Mbit/s (genre 95). Si oui, c'est votre application cliente qui ne suit pas ou un problème de disque sur le client.
Cordialement, -- Q: Connaissez-vous la différence entre l'ignorance et l'apathie ? R: J'en sais rien et je m'en fous. Mathieu Goutelle - http://www.cadichonne.net/
Bonsoir,
Dans l'article <473a0b82$0$25950$ba4acef3@news.orange.fr>, Emmanuel a
écrit :
Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur
et/ou mes clients pour permettre de réguler le traffic sans aller
jusqu'au débordement de buffer (le slow restart plombe les performances).
Sur un LAN, je doute que ce soit ça qui plombe les performances :
compte tenu du délai d'aller-retour très court, la dynamique de TCP
doit être très bonne. En plus, que vous fassiez de la limitation de
débit au niveau du serveur ou dans le switch (parce que c'est ce qu'il
se passe, hein), il y aura à un moment ou à un autre des paquets perdus
et donc un TCP slow start.
Sincèrement, je pencherais plus pour un problème sur la machine cliente
qui n'arrive pas à suivre... Pour s'en assurer, il suffirait de faire
un test à la iperf entre serveur et client et vérifier que vous obtenez
un très grosse part de 100Mbit/s (genre 95). Si oui, c'est votre
application cliente qui ne suit pas ou un problème de disque sur le
client.
Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - http://www.cadichonne.net/
Dans l'article <473a0b82$0$25950$, Emmanuel a écrit :
Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur et/ou mes clients pour permettre de réguler le traffic sans aller jusqu'au débordement de buffer (le slow restart plombe les performances).
Sur un LAN, je doute que ce soit ça qui plombe les performances : compte tenu du délai d'aller-retour très court, la dynamique de TCP doit être très bonne. En plus, que vous fassiez de la limitation de débit au niveau du serveur ou dans le switch (parce que c'est ce qu'il se passe, hein), il y aura à un moment ou à un autre des paquets perdus et donc un TCP slow start.
Sincèrement, je pencherais plus pour un problème sur la machine cliente qui n'arrive pas à suivre... Pour s'en assurer, il suffirait de faire un test à la iperf entre serveur et client et vérifier que vous obtenez un très grosse part de 100Mbit/s (genre 95). Si oui, c'est votre application cliente qui ne suit pas ou un problème de disque sur le client.
Cordialement, -- Q: Connaissez-vous la différence entre l'ignorance et l'apathie ? R: J'en sais rien et je m'en fous. Mathieu Goutelle - http://www.cadichonne.net/
kurtz le pirate
In article <473a0b82$0$25950$, Emmanuel wrote:
Bonsoir,
J'ai un gros problème d'équilibrage de charge sur mon réseau. Voilà la topologie :
Le serveur est un serveur de base de données sous Debian/Sarge Les clients sont des XP Le switch 1 est un NetGear GSM7352S (48p/Gbit) Le switch 2 est un Netgear FS750T2 (48p/100Mb)
Le serveur est connecté en Gb Le client 1 aussi Le lien entre les switchs et le lien du client 2 sont à 100Mb
Mon problème est le suivant : Quand Client2 établit une connexion au serveur et commence à lire de données, celles-ci partent plus vite du serveur que ce que le client n'accepte (normal vu la diff de vitesse des liens). Au bout d'un certain temps, la quantité émise par le serveur est telle que le buffer du switch 2 explose et que la connexion TCP fait un slow restart. Le client 1 ne connait, quant à lui aucun pb de performance.
Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur et/ou mes clients pour permettre de réguler le traffic sans aller jusqu'au débordement de buffer (le slow restart plombe les performances).
Bien sûr, le cas présenté ici est isolé, dans la vraie vie j'ai plusieurs serveurs et +++ clients.
Merci d'avance pour vos lumières.
Manu
il faudrait avoir des précisions sur le "client2 etablit une connexion" et le "commence a lire" : c'est du ftp ? http ? autre ?
normalement, ce genre de chose est bien géré au niveau couches réseau.
-- klp
In article <473a0b82$0$25950$ba4acef3@news.orange.fr>,
Emmanuel <ebernat_nospam@free.fr> wrote:
Bonsoir,
J'ai un gros problème d'équilibrage de charge sur mon réseau.
Voilà la topologie :
Le serveur est un serveur de base de données sous Debian/Sarge
Les clients sont des XP
Le switch 1 est un NetGear GSM7352S (48p/Gbit)
Le switch 2 est un Netgear FS750T2 (48p/100Mb)
Le serveur est connecté en Gb
Le client 1 aussi
Le lien entre les switchs et le lien du client 2 sont à 100Mb
Mon problème est le suivant :
Quand Client2 établit une connexion au serveur et commence à lire de
données, celles-ci partent plus vite du serveur que ce que le client
n'accepte (normal vu la diff de vitesse des liens).
Au bout d'un certain temps, la quantité émise par le serveur est telle que
le buffer du switch 2 explose et que la connexion TCP fait un slow
restart.
Le client 1 ne connait, quant à lui aucun pb de performance.
Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur
et/ou mes clients pour permettre de réguler le traffic sans aller
jusqu'au débordement de buffer (le slow restart plombe les performances).
Bien sûr, le cas présenté ici est isolé, dans la vraie vie j'ai plusieurs
serveurs et +++ clients.
Merci d'avance pour vos lumières.
Manu
il faudrait avoir des précisions sur le "client2 etablit une connexion"
et le "commence a lire" : c'est du ftp ? http ? autre ?
normalement, ce genre de chose est bien géré au niveau couches réseau.
Le serveur est un serveur de base de données sous Debian/Sarge Les clients sont des XP Le switch 1 est un NetGear GSM7352S (48p/Gbit) Le switch 2 est un Netgear FS750T2 (48p/100Mb)
Le serveur est connecté en Gb Le client 1 aussi Le lien entre les switchs et le lien du client 2 sont à 100Mb
Mon problème est le suivant : Quand Client2 établit une connexion au serveur et commence à lire de données, celles-ci partent plus vite du serveur que ce que le client n'accepte (normal vu la diff de vitesse des liens). Au bout d'un certain temps, la quantité émise par le serveur est telle que le buffer du switch 2 explose et que la connexion TCP fait un slow restart. Le client 1 ne connait, quant à lui aucun pb de performance.
Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur et/ou mes clients pour permettre de réguler le traffic sans aller jusqu'au débordement de buffer (le slow restart plombe les performances).
Bien sûr, le cas présenté ici est isolé, dans la vraie vie j'ai plusieurs serveurs et +++ clients.
Merci d'avance pour vos lumières.
Manu
il faudrait avoir des précisions sur le "client2 etablit une connexion" et le "commence a lire" : c'est du ftp ? http ? autre ?
normalement, ce genre de chose est bien géré au niveau couches réseau.
-- klp
Emmanuel
"kurtz le pirate" a écrit dans le message de news:
il faudrait avoir des précisions sur le "client2 etablit une connexion" et le "commence a lire" : c'est du ftp ? http ? autre ?
normalement, ce genre de chose est bien géré au niveau couches réseau.
-- klp
Merci à tous pour votre aide.
Ce n'est pas l'établissement de connexion qui pose problème. Le protocole, c'est de la base de données (c'est un serveur Hyper File). J'ai fait des captures avec wireshark et je constate tjs le même phénomène : une fois que le serveur et un client dialoguent, le serveur envoie entre 30 et 50% de trames IP en plus de ce que le client acquitte, du coup ils sont de plus en plus déphasés. Au bout d'un certain temps, j'ai carément un paquets de trames qui disparaissent dans le switch 2 et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui plombe tout. Comme tous les clients du switch 2 ont ce pb, le réseau s'effondre.
Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un débit de env. 50Mbps entre le serveur et les clients du switch 2. ça me semble bas.
Manu
"kurtz le pirate" <kurtzlepirate@yahoo.fr> a écrit dans le message de news:
kurtzlepirate-5CD31E.19015414112007@news-1.proxad.net...
il faudrait avoir des précisions sur le "client2 etablit une connexion"
et le "commence a lire" : c'est du ftp ? http ? autre ?
normalement, ce genre de chose est bien géré au niveau couches réseau.
--
klp
Merci à tous pour votre aide.
Ce n'est pas l'établissement de connexion qui pose problème.
Le protocole, c'est de la base de données (c'est un serveur Hyper File).
J'ai fait des captures avec wireshark et je constate tjs le même phénomène :
une fois que le serveur et un client dialoguent, le serveur envoie entre 30
et 50% de trames
IP en plus de ce que le client acquitte, du coup ils sont de plus en plus
déphasés.
Au bout d'un certain temps, j'ai carément un paquets de trames qui
disparaissent dans le switch 2
et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui
plombe tout.
Comme tous les clients du switch 2 ont ce pb, le réseau s'effondre.
Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un
débit de env. 50Mbps entre le serveur
et les clients du switch 2. ça me semble bas.
"kurtz le pirate" a écrit dans le message de news:
il faudrait avoir des précisions sur le "client2 etablit une connexion" et le "commence a lire" : c'est du ftp ? http ? autre ?
normalement, ce genre de chose est bien géré au niveau couches réseau.
-- klp
Merci à tous pour votre aide.
Ce n'est pas l'établissement de connexion qui pose problème. Le protocole, c'est de la base de données (c'est un serveur Hyper File). J'ai fait des captures avec wireshark et je constate tjs le même phénomène : une fois que le serveur et un client dialoguent, le serveur envoie entre 30 et 50% de trames IP en plus de ce que le client acquitte, du coup ils sont de plus en plus déphasés. Au bout d'un certain temps, j'ai carément un paquets de trames qui disparaissent dans le switch 2 et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui plombe tout. Comme tous les clients du switch 2 ont ce pb, le réseau s'effondre.
Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un débit de env. 50Mbps entre le serveur et les clients du switch 2. ça me semble bas.
Manu
Mathieu Goutelle
Bonsoir,
Dans l'article <473cb575$0$27386$, Emmanuel a écrit :
une fois que le serveur et un client dialoguent, le serveur envoie entre 30 et 50% de trames IP en plus de ce que le client acquitte, du coup ils sont de plus en plus déphasés. Au bout d'un certain temps, j'ai carément un paquets de trames qui disparaissent dans le switch 2 et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui plombe tout.
Il ne plombe pas tout : il fait son boulot ! ;-) Comme ton serveur tente d'envoyer à plus de 100 Mbit/s, il faut bien que quelque chose le limite et ce quelque chose, c'est TCP qui réagit à une perte de paquets.
Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un débit de env. 50Mbps entre le serveur et les clients du switch 2. ça me semble bas.
Je suis d'accord : tu devrais au moins faire du 80-90 avec iperf, sans trafic concurrent.
Tu peux regarder les compteurs du switch, pour voir si tu n'as pas trop d'erreurs. S'il y a des erreurs, regarde au niveau du cablâge ou des cartes. Essaie aussi d'augmenter sur les clients surtout le buffer TCP (http://psc.edu/networking/projects/tcptune/). Vois aussi du côté de SACK (Selective Acknowledgement) car je ne sais pas si c'est activé par défaut sous Windows.
Cordialement, -- Q: Connaissez-vous la différence entre l'ignorance et l'apathie ? R: J'en sais rien et je m'en fous. Mathieu Goutelle - http://www.cadichonne.net/
Bonsoir,
Dans l'article <473cb575$0$27386$ba4acef3@news.orange.fr>, Emmanuel a
écrit :
une fois que le serveur et un client dialoguent, le serveur envoie
entre 30 et 50% de trames IP en plus de ce que le client acquitte, du
coup ils sont de plus en plus déphasés. Au bout d'un certain temps,
j'ai carément un paquets de trames qui disparaissent dans le switch 2
et le client emet alors un TCP-Out of order. Il s'ensuit le slow
restart qui plombe tout.
Il ne plombe pas tout : il fait son boulot ! ;-)
Comme ton serveur tente d'envoyer à plus de 100 Mbit/s, il faut bien
que quelque chose le limite et ce quelque chose, c'est TCP qui réagit à
une perte de paquets.
Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et
j'ai un débit de env. 50Mbps entre le serveur et les clients du
switch 2. ça me semble bas.
Je suis d'accord : tu devrais au moins faire du 80-90 avec iperf, sans
trafic concurrent.
Tu peux regarder les compteurs du switch, pour voir si tu n'as pas trop
d'erreurs. S'il y a des erreurs, regarde au niveau du cablâge ou des
cartes. Essaie aussi d'augmenter sur les clients surtout le buffer TCP
(http://psc.edu/networking/projects/tcptune/). Vois aussi du côté de
SACK (Selective Acknowledgement) car je ne sais pas si c'est activé par
défaut sous Windows.
Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - http://www.cadichonne.net/
Dans l'article <473cb575$0$27386$, Emmanuel a écrit :
une fois que le serveur et un client dialoguent, le serveur envoie entre 30 et 50% de trames IP en plus de ce que le client acquitte, du coup ils sont de plus en plus déphasés. Au bout d'un certain temps, j'ai carément un paquets de trames qui disparaissent dans le switch 2 et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui plombe tout.
Il ne plombe pas tout : il fait son boulot ! ;-) Comme ton serveur tente d'envoyer à plus de 100 Mbit/s, il faut bien que quelque chose le limite et ce quelque chose, c'est TCP qui réagit à une perte de paquets.
Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un débit de env. 50Mbps entre le serveur et les clients du switch 2. ça me semble bas.
Je suis d'accord : tu devrais au moins faire du 80-90 avec iperf, sans trafic concurrent.
Tu peux regarder les compteurs du switch, pour voir si tu n'as pas trop d'erreurs. S'il y a des erreurs, regarde au niveau du cablâge ou des cartes. Essaie aussi d'augmenter sur les clients surtout le buffer TCP (http://psc.edu/networking/projects/tcptune/). Vois aussi du côté de SACK (Selective Acknowledgement) car je ne sais pas si c'est activé par défaut sous Windows.
Cordialement, -- Q: Connaissez-vous la différence entre l'ignorance et l'apathie ? R: J'en sais rien et je m'en fous. Mathieu Goutelle - http://www.cadichonne.net/
Elekaj34
"kurtz le pirate" a écrit dans le message de news:
il faudrait avoir des précisions sur le "client2 etablit une connexion" et le "commence a lire" : c'est du ftp ? http ? autre ?
normalement, ce genre de chose est bien géré au niveau couches réseau.
-- klp
Merci à tous pour votre aide.
Ce n'est pas l'établissement de connexion qui pose problème. Le protocole, c'est de la base de données (c'est un serveur Hyper File). J'ai fait des captures avec wireshark et je constate tjs le même phénomène : une fois que le serveur et un client dialoguent, le serveur envoie entre 30 et 50% de trames IP en plus de ce que le client acquitte, du coup ils sont de plus en plus déphasés. Au bout d'un certain temps, j'ai carément un paquets de trames qui disparaissent dans le switch 2 et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui plombe tout. Comme tous les clients du switch 2 ont ce pb, le réseau s'effondre.
Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un débit de env. 50Mbps entre le serveur et les clients du switch 2. ça me semble bas.
Manu
J'ai eu il y a quelques temps le même problème que toi. Le remplacement du switch a résolu le problème.
De plus, il arrive (mais c'est très rare) que l'utilisation de switch de marque différentes pose problème (par ex netgear et 3com ne semblent pas faire de copinage).
Cordialement,
Elekaj
"kurtz le pirate" <kurtzlepirate@yahoo.fr> a écrit dans le message de news:
kurtzlepirate-5CD31E.19015414112007@news-1.proxad.net...
il faudrait avoir des précisions sur le "client2 etablit une connexion"
et le "commence a lire" : c'est du ftp ? http ? autre ?
normalement, ce genre de chose est bien géré au niveau couches réseau.
--
klp
Merci à tous pour votre aide.
Ce n'est pas l'établissement de connexion qui pose problème.
Le protocole, c'est de la base de données (c'est un serveur Hyper File).
J'ai fait des captures avec wireshark et je constate tjs le même phénomène :
une fois que le serveur et un client dialoguent, le serveur envoie entre 30
et 50% de trames
IP en plus de ce que le client acquitte, du coup ils sont de plus en plus
déphasés.
Au bout d'un certain temps, j'ai carément un paquets de trames qui
disparaissent dans le switch 2
et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui
plombe tout.
Comme tous les clients du switch 2 ont ce pb, le réseau s'effondre.
Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un
débit de env. 50Mbps entre le serveur
et les clients du switch 2. ça me semble bas.
Manu
J'ai eu il y a quelques temps le même problème que toi. Le remplacement
du switch a résolu le problème.
De plus, il arrive (mais c'est très rare) que l'utilisation de switch de
marque différentes pose problème (par ex netgear et 3com ne semblent pas
faire de copinage).
"kurtz le pirate" a écrit dans le message de news:
il faudrait avoir des précisions sur le "client2 etablit une connexion" et le "commence a lire" : c'est du ftp ? http ? autre ?
normalement, ce genre de chose est bien géré au niveau couches réseau.
-- klp
Merci à tous pour votre aide.
Ce n'est pas l'établissement de connexion qui pose problème. Le protocole, c'est de la base de données (c'est un serveur Hyper File). J'ai fait des captures avec wireshark et je constate tjs le même phénomène : une fois que le serveur et un client dialoguent, le serveur envoie entre 30 et 50% de trames IP en plus de ce que le client acquitte, du coup ils sont de plus en plus déphasés. Au bout d'un certain temps, j'ai carément un paquets de trames qui disparaissent dans le switch 2 et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui plombe tout. Comme tous les clients du switch 2 ont ce pb, le réseau s'effondre.
Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un débit de env. 50Mbps entre le serveur et les clients du switch 2. ça me semble bas.
Manu
J'ai eu il y a quelques temps le même problème que toi. Le remplacement du switch a résolu le problème.
De plus, il arrive (mais c'est très rare) que l'utilisation de switch de marque différentes pose problème (par ex netgear et 3com ne semblent pas faire de copinage).
Cordialement,
Elekaj
Pascal Hambourg
Salut,
Au bout d'un certain temps, la quantité émise par le serveur est telle que le buffer du switch 2 explose
Il n'y a pas un mécanisme de contrôle de flux au niveau ethernet (802.3x) censé empêcher ça ?
Salut,
Au bout d'un certain temps, la quantité émise par le serveur est telle que
le buffer du switch 2 explose
Il n'y a pas un mécanisme de contrôle de flux au niveau ethernet
(802.3x) censé empêcher ça ?
