Forum Linux.redhat Probleme reseau sur cluster gigabit

Posté par  .
Étiquettes :
0
5
sept.
2006
Bonjour.
J'ai un probleme reseau TCP/IP sur un cluster de PC :

11 bi Xeon 2.66, fedora core 4, ethernet GigaBit e1000, switch gigabit

Voici mon probleme :

lorsque j'utilise une application client-serveur TCP avec un serveur sur une machine et deux clients sur deux autres machines, ces clients envoyant beaucoup de messages au serveur (10 Mo /s chacun), alors mon serveur recoit bien ces messages mais d'une facon irreguliere. C'est a dire qu'il marque beaucoup de pauses lors de la reception.
Lorsque je fait ifconfig sur le serveur, je vois un nombre tres important de dropped messages, qui augmente tres rapidement, par contre les autres chiffres sont normaux (pas de collisions par exemple). Le ifconfig du cote client ne donne rien de special.
J'ai teste mon reseau avec plusieurs applications, le probleme est toujours le meme. Ce qui a l'air de poser probleme n'est pas la quantite d'information qui transite mais plutot le fait que le serveur recoivent plusieurs flux en parallele( je ne suis pas sur).
Je me suis donc renseigne sur le TCP tuning. J'ai change la taille des differents buffers, mais cela n'a pas l'air d'avoir change qqchose.
J'ai vu que sur les e1000 on pouvait desactiver le DITR (algorithme du calcul du nombre d'interruptions de la carte reseau). Mais je n'ai pas pu teste ce prametre pour l'instant.

Voila, si qqun voit une solution a ce probleme, merci beaucoup de me donner un coup de main.

Voici donc ma configuration actuelle :

net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_abc = 1
net.ipv4.tcp_congestion_control = bic
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_moderate_rcvbuf = 0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_frto = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216
net.ipv4.tcp_mem = 393216 524288 786432
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_ecn = 0
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_fack = 1
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_max_tw_buckets = 180000
net.ipv4.tcp_max_orphans = 131072
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1

Le resultat du ifconfig sur le serveur :

eth0 Link encap:Ethernet HWaddr 00:E0:81:51:2E:2C
inet addr:129.88.99.21 Bcast:129.88.99.63 Mask:255.255.255.192
inet6 addr: fe80::2e0:81ff:fe51:2e2c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:242839692 errors:0 dropped:266120 overruns:0 frame:0
TX packets:126106747 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3980310330 (3.7 GiB) TX bytes:3346390005 (3.1 GiB)
Base address:0x2080 Memory:c2200000-c2220000
  • # drop

    Posté par  . Évalué à 3.

    J'y connais pas grand chose en TCP tunning, mais je serais toi, je chercherai pourquoi il drop ces paquets ... à priori, TCP drop quand les checksum sont incorrects, c'est la première idée qui m'est venu en tête, mais y'en a peut-être d'autres.

    Maintenant, reste a savoir si c'est ta couche TCP cliente qui calcul mal ou celle du serveur ...

    La première chose à faire serais un petit coup de tcpdump histoire de voir c'qui se passe de plus près.
  • # anti d0s

    Posté par  . Évalué à 1.

    juste une idée comme ça: peut-être est-ce une protection contre le déni de service distribué ?
    Il y aurait donc un paramètre à désactiver dans le noyau (peut-être).
  • # Calculs

    Posté par  . Évalué à 2.

    Si on compte depuis la dernière fois que ta carte réseau à été ifupée, tu as 266120 paquets droppés sur 242839692 ça fait environ 0.1%.

    C'est pas énorme, à mon avis pas assez pour qu'un ralentissement se fasse sentir.

    Après, si ta machine tourne depuis six mois et droppe seulement depuis deux semaines, le 0.1% ne correspond plus à rien.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.