Pages : 1
#1 Le 21/10/2007, à 23:00
- PhENTZ
[Résolu] ping: sendmsg: no buffer space available
Bonjour,
Cela fait quelques semaines que je m'arrache les cheveux sur un problème.
Par chance, depuis hier j'arrive à le reproduire de façon systématique. Je peux donc vous le soumettre ;-)
J'ai un serveur sur Edubuntu 7.10 et un seul poste client léger.
Sur le poste client je lance un ou plusieurs Xaos en mode "pilotage automatique". C'est un programme de dessin de fractale dont l'intérêt ici est de me générer du traffic réseau.
Pendant ce temps je lance sur la console du serveur un ping sur l'ip du poste client.
Jusqu'à trois instance de Xaos, le ping ralentis mais réponds toujours.
Lorsque je lance la quatrième instance, le ping se bloque une dizaine de seconde puis affiche "ping: sendmsg: no buffer space available".
Si je quitte une des instances de Xaos. Le ping refonctionne normalement (après avoir présenté quelques valeurs à plus de 30 ou 40s !!).
Ma question, pour le moment, est simple : Est-ce normal qu'une activité réseau aussi basique puisse faire "tomber" le ping ?
Voici quelques infos sur l'environnement :
- la CPU du serveur est à moins de 20% (quad-core) ;
- la ram du serveur est à moins de 20% (5 Go au total) ;
- le réseau est à 1Gbps sur le serveur, 100 Mbps sur le client, un switch entre les deux et aucun autre périphérique ;
- l'installation est "neuve" et aucun services ou application particulière n'a été installé ;
- j'ai le même comportement sur un autre matériel serveur ;
- j'ai le même comportement sur Edubuntu 7.04
Voilà, j'attends vos questions de pied ferme ;-)
Dernière modification par PhENTZ (Le 27/10/2007, à 23:47)
Hors ligne
#2 Le 21/10/2007, à 23:14
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
J'ai décrit la situation "facilement reproductible".
En fait, voici ce qui se passe en utilisation normale :
Je démarre une douzaine de postes clients en boot PXE sans aucun problème. Tous le monde se connecte et commence à utiliser le bureau Gnome.
Le serveur tient parfaitement la charge.
Au bout d'une à deux heures, un ou deux postes se bloquent. En les redémarrant, impossible de booter en PXE : Le serveur DHCP ne réponds plus !!
Impossible également de démarrer de nouveaux postes. Impossible d'ouvrir de nouvelles connexions SSH au serveur (alors que les sessions existantes fonctionnent).
Les affichages X des clients commencent à sérieusement ralentir (lag) alors que la CPU du serveur est sous-exploitée !
Un tiers à la moité des clients finissent par "tomber" et la seule solution est de redémarrer le serveur complètement (un simple redémarrage des services dhcpd et sshd ne suffit pas).
Hors ligne
#3 Le 22/10/2007, à 00:05
- NP
Re : [Résolu] ping: sendmsg: no buffer space available
Hihi !
Le problème est qu'il y probablement trop de traffic ICMP ou UDP pour que cela soit supporté par ta carte. Le message d'erreur est bien clair, elle n'a plus d'espace mémoire !
Tu dois avoir des services de découverte du réseau ou de services.
Tu n'es pas sur un réseau de classe A avec KDE et Lisa d'activé par hasard ?
T'as certainement pas mal de requêtes ARP qui se baladent sur ton réseau.
Peux-tu donner le résultat de :
- ifconfig
- arp -n
- ps ax | grep lisa
- netstat -s
Si en tuant lisa ça ne change rien envoi moi un dump de ton trafic réseau.
Hors ligne
#4 Le 22/10/2007, à 09:25
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Je suis en classe C : 192.168.250.0/24
J'avais entendu parler de cette histoire de Lisa mais dans mon cas il n'y a pas KDE, le bureau par défaut est Gnome.
De toute façon s'il y a des services intégrés au bureau Gnome, ils sont lancés sur le serveur et pas sur le client (le client est un client léger qui lance une session ldm/ssh).
Je poste dès que possible les résultats ifconfig, arp, ps, netstat.
Hors ligne
#5 Le 22/10/2007, à 10:49
- NP
Re : [Résolu] ping: sendmsg: no buffer space available
Balance un dump de ton trafic aussi ça me sera utile je pense.
tcpdump en cli ou wireshark en gui
Hors ligne
#6 Le 22/10/2007, à 21:00
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Voici les premières infos :
C'est eth0 qui est utilisé, eth1 n'est pas cablé.
philippe@bergamotte:~$ ifconfig
eth0 Lien encap:Ethernet HWaddr 00:1B:FC:99:D6:EE
inet adr:192.168.250.8 Bcast:192.168.250.255 Masque:255.255.255.0
adr inet6: fe80::21b:fcff:fe99:d6ee/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:668214 erreurs:0 :0 overruns:0 frame:0
TX packets:979134 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:166653357 (158.9 MB) Octets transmis:1117740126 (1.0 GB)
Interruption:19
eth1 Lien encap:Ethernet HWaddr 00:1B:FC:99:DC:A3
inet adr:192.168.0.254 Bcast:192.168.0.255 Masque:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:0 (0.0 b) Octets transmis:0 (0.0 b)
Interruption:17
lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hà´te
UP LOOPBACK RUNNING MTU:16436 Metric:1
Packets reçus:266047 erreurs:0 :0 overruns:0 frame:0
TX packets:266047 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:1093627148 (1.0 GB) Octets transmis:1093627148 (1.0 GB)Rien pour lisa :
philippe@bergamotte:~$ ps ax | grep lisa
9949 pts/0 S+ 0:00 grep lisaPour les autres infos, je refais un test en situation (isolement réseau et reboot seveur) et je poste ...
Hors ligne
#7 Le 22/10/2007, à 21:51
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Bon ca y est j'ai refait une séance de test en capturant à des instants précis les éléments demandés. Les infos ont été capturées par le script suivant :
#!/bin/sh
date
ifconfig
arp -n
ps ax | grep lisa
netstat -sPendant tous le temps du test (5mn) j'ai fait tourné un :
sudo tcpdump -n -w dump1Le fichier pèse 180 Mo !! (66 Mo en bz2). Je vais extraire avec wireshark des portions significatives.
Voici les moments auxquels j'ai capturé des stats :
1- Après démarrage du serveur, sans activité particulière
2- Allumage du PC client (boot PXE, DHCP, TFTP, ... jusqu'à l'écran X de login ldm)
+ démarrage d'un ping depuis le serveur sur le poste client (192.168.250.95)
3- Login sur le poste client, petite musique et affichage du bureau Gnome
4- Lancement de 4 instances de Xaos
5- Activation du "pilotage automatique" (touche a) sur 2 des instances Xaos
6- Activation du "pilotage automatique" (touche a) sur une 3eme instance Xaos
7- Le ping vers le client "tombe"
8- Le ping vers le client est toujours "tombé"
9- Désactivation du "pilotage automatique" (touche a) d'une des 3 instances Xaos : Le ping refonctionne
10- Désactivation du "pilotage automatique" (touche a) des 2 instances Xaos restantes
11- Fermeture de la session Gnome sur le client et arrêt du poste client
Je tiens à votre disposition tous les fichiers. Je vais poster des extraits qui me semblent significatifs.
Hors ligne
#8 Le 22/10/2007, à 22:00
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Voici les stats en t8 (Le ping vers le client est toujours "tombé") :
lundi 22 octobre 2007, 21:26:39 (UTC+0200)
eth0 Lien encap:Ethernet HWaddr 00:1B:FC:99:D6:EE
inet adr:192.168.250.8 Bcast:192.168.250.255 Masque:255.255.255.0
adr inet6: fe80::21b:fcff:fe99:d6ee/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:399456 erreurs:0 :0 overruns:0 frame:0
TX packets:756700 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:34629549 (33.0 MB) Octets transmis:1076256362 (1.0 GB)
Interruption:19eth1 Lien encap:Ethernet HWaddr 00:1B:FC:99:DC:A3
inet adr:192.168.0.254 Bcast:192.168.0.255 Masque:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:0 (0.0 b) Octets transmis:0 (0.0 b)
Interruption:17lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hà´te
UP LOOPBACK RUNNING MTU:16436 Metric:1
Packets reçus:140823 erreurs:0 :0 overruns:0 frame:0
TX packets:140823 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:1003260906 (956.7 MB) Octets transmis:1003260906 (956.7 MB)Address HWtype HWaddress Flags Mask Iface
192.168.250.95 ether 00:13:72:CD:08:89 C eth0
192.168.250.2 (incomplet) eth0
6892 tty3 S+ 0:00 grep lisa
Ip:
540529 paquets reçus au total
0 réacheminés
0 paquets arrivant rejetés
540529 paquets entrants délivrés
898085 requêtes envoyées
43 paquets sortants rejetés
Icmp:
144 Messages ICMP reçus
0 messages ICMP entrant échoués
Histogramme d'entrée ICMP
destination injoignable: 18
echo replies: 126
426 messages ICMP envoyés
0 messages ICMP échoués
Histogramme de sortie ICMP
destination injoignable: 426
Tcp:
39 ouvertures de connexions actives
40 connexions passives ouvertes
0 tentatives de connexion échouées
2 reinitialisation de la connection détéctée
45 connexions établies
535653 segments reçus
893581 segments envoyés
1 segments retransmis
0 mauvais segments reçus
0 réinitailisations envoyées
Udp:
4324 packets reçus
408 paquets reçus sur un port inconnu
0 erreurs de réception de paquet
4332 paquets envoyés
UdpLite:
TcpExt:
17 TCP sockets finished time wait in fast timer
353 accusés de réception envoyés en retard
9702 paquets directement mis en attente dans la file d'attente recvmsg.
56 of bytes directly received from backlog
40320 of bytes directly received from prequeue
95235 en-têtes de paquets prédits
1429 packets header predicted and directly queued to user
960 acknowledgments not containing data received
449095 accusés de réception prédits
0 TCP data loss events
1 other TCP timeouts
1 connections reset due to early user close
IpExt:
InMcastPkts: 30
OutMcastPkts: 34
InBcastPkts: 5
Dernière modification par PhENTZ (Le 22/10/2007, à 22:02)
Hors ligne
#9 Le 22/10/2007, à 22:04
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Voici les stats en t4 (Lancement de 4 instances de Xaos) :
lundi 22 octobre 2007, 21:25:08 (UTC+0200)
eth0 Lien encap:Ethernet HWaddr 00:1B:FC:99:D6:EE
inet adr:192.168.250.8 Bcast:192.168.250.255 Masque:255.255.255.0
adr inet6: fe80::21b:fcff:fe99:d6ee/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:34837 erreurs:0 :0 overruns:0 frame:0
TX packets:48303 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:8210091 (7.8 MB) Octets transmis:57693818 (55.0 MB)
Interruption:19eth1 Lien encap:Ethernet HWaddr 00:1B:FC:99:DC:A3
inet adr:192.168.0.254 Bcast:192.168.0.255 Masque:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:0 (0.0 b) Octets transmis:0 (0.0 b)
Interruption:17lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hà´te
UP LOOPBACK RUNNING MTU:16436 Metric:1
Packets reçus:20609 erreurs:0 :0 overruns:0 frame:0
TX packets:20609 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:29331246 (27.9 MB) Octets transmis:29331246 (27.9 MB)Address HWtype HWaddress Flags Mask Iface
192.168.250.95 ether 00:13:72:CD:08:89 C eth0
192.168.250.2 (incomplet) eth0
6837 tty3 S+ 0:00 grep lisa
Ip:
55468 paquets reçus au total
0 réacheminés
0 paquets arrivant rejetés
55468 paquets entrants délivrés
68898 requêtes envoyées
Icmp:
109 Messages ICMP reçus
0 messages ICMP entrant échoués
Histogramme d'entrée ICMP
destination injoignable: 18
echo replies: 91
426 messages ICMP envoyés
0 messages ICMP échoués
Histogramme de sortie ICMP
destination injoignable: 426
Tcp:
39 ouvertures de connexions actives
40 connexions passives ouvertes
0 tentatives de connexion échouées
2 reinitialisation de la connection détéctée
45 connexions établies
50627 segments reçus
64442 segments envoyés
0 segments retransmis
0 mauvais segments reçus
0 réinitailisations envoyées
Udp:
4324 packets reçus
408 paquets reçus sur un port inconnu
0 erreurs de réception de paquet
4332 paquets envoyés
UdpLite:
TcpExt:
4 TCP sockets finished time wait in fast timer
313 accusés de réception envoyés en retard
9702 paquets directement mis en attente dans la file d'attente recvmsg.
56 of bytes directly received from backlog
40320 of bytes directly received from prequeue
22580 en-têtes de paquets prédits
1429 packets header predicted and directly queued to user
792 acknowledgments not containing data received
33280 accusés de réception prédits
0 TCP data loss events
1 connections reset due to early user close
IpExt:
InMcastPkts: 30
OutMcastPkts: 34
InBcastPkts: 5
Hors ligne
#10 Le 22/10/2007, à 22:05
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Voici les stats en t11 (le client est arrêté) :
lundi 22 octobre 2007, 21:28:39 (UTC+0200)
eth0 Lien encap:Ethernet HWaddr 00:1B:FC:99:D6:EE
inet adr:192.168.250.8 Bcast:192.168.250.255 Masque:255.255.255.0
adr inet6: fe80::21b:fcff:fe99:d6ee/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:655805 erreurs:0 :0 overruns:0 frame:0
TX packets:1252900 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:53677217 (51.1 MB) Octets transmis:1787250250 (1.6 GB)
Interruption:19eth1 Lien encap:Ethernet HWaddr 00:1B:FC:99:DC:A3
inet adr:192.168.0.254 Bcast:192.168.0.255 Masque:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:0 (0.0 b) Octets transmis:0 (0.0 b)
Interruption:17lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hà´te
UP LOOPBACK RUNNING MTU:16436 Metric:1
Packets reçus:228843 erreurs:0 :0 overruns:0 frame:0
TX packets:228843 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:1681276078 (1.5 GB) Octets transmis:1681276078 (1.5 GB)Address HWtype HWaddress Flags Mask Iface
192.168.250.95 ether 00:13:72:CD:08:89 C eth0
192.168.250.2 (incomplet) eth0
6960 tty3 S+ 0:00 grep lisa
Ip:
884670 paquets reçus au total
0 réacheminés
0 paquets arrivant rejetés
884670 paquets entrants délivrés
1481729 requêtes envoyées
56 paquets sortants rejetés
Icmp:
251 Messages ICMP reçus
0 messages ICMP entrant échoués
Histogramme d'entrée ICMP
destination injoignable: 18
echo replies: 233
430 messages ICMP envoyés
0 messages ICMP échoués
Histogramme de sortie ICMP
destination injoignable: 430
Tcp:
39 ouvertures de connexions actives
41 connexions passives ouvertes
0 tentatives de connexion échouées
8 reinitialisation de la connection détéctée
1 connexions établies
879683 segments reçus
1477114 segments envoyés
1 segments retransmis
0 mauvais segments reçus
0 réinitailisations envoyées
Udp:
4324 packets reçus
412 paquets reçus sur un port inconnu
0 erreurs de réception de paquet
4332 paquets envoyés
UdpLite:
TcpExt:
17 TCP sockets finished time wait in fast timer
427 accusés de réception envoyés en retard
9714 paquets directement mis en attente dans la file d'attente recvmsg.
56 of bytes directly received from backlog
40348 of bytes directly received from prequeue
149257 en-têtes de paquets prédits
1430 packets header predicted and directly queued to user
1315 acknowledgments not containing data received
741387 accusés de réception prédits
0 TCP data loss events
1 other TCP timeouts
1 DSACKs received
4 connections reset due to early user close
IpExt:
InMcastPkts: 30
OutMcastPkts: 34
InBcastPkts: 5
Hors ligne
#11 Le 22/10/2007, à 22:10
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Dernier commentaire et promis, j'arrêt d'innonder ce fil ;-)
Avant de générer la "charge" sur le client (jusqu'à t4 inclus), le ping est de 0,1ms.
Lorsqu'il y a 2 Xaos en "pilotage automatique", le ping descent à 10 ms.
Avec 3 Xaos en "pilotage automatique", le ping affiche "ping: sendmsg: no buffer space available"
Voici pour info les stats lorsque j'ai arrêté la commande ping :
- 286 packets
- 18% loss
- Durée 304s
- TTL min 0,083 ms
- TTL avg 3,2 s !
- TTL max 68 s !!
- TTL mdev 13,8 s !!!
- pipe 49 (là je ne sais pas ce que c'est !)
Hors ligne
#12 Le 23/10/2007, à 01:08
- NP
Re : [Résolu] ping: sendmsg: no buffer space available
Houlà mais qu'est ce t'as mangé toi ? Vas y molo, j'arrive pas à suivre moi ! lol
Je voulais avoir toutes ces stats pour te montrer une chose :
C'est un programme de dessin de fractale dont l'intérêt ici est de me générer du traffic réseau.
Ma question, pour le moment, est simple : Est-ce normal qu'une activité réseau aussi basique puisse faire "tomber" le ping ?
La réponse est oui 
Quelques chiffres significatifs :
Packets reçus:399456 erreurs:0 :0 overruns:0 frame:0
TX packets:756700 errors:0 dropped:0 overruns:0 carrier:0
Ip:
540529 paquets reçus au total
540529 paquets entrants délivrés
898085 requêtes envoyées
43 paquets sortants rejetés
9702 paquets directement mis en attente dans la file d'attente recvmsg.
40320 of bytes directly received from prequeue
On a donc ta carte réseau qui commence à saturer sur cet ordi mais elle l'est complètement sur l'autre. L'ordi sur lequel tu es émet beaucoup de paquets qui saturent l'autre ordi.
2 raisons :
- Tu as une carte réseau pas très performante donc le processeur doit bosser beaucoup. D'ailleurs regarde son usage il doit monter à près de 100% non ?
- Tu as un processeur pas très puissant. Ça influe beaucoup sur un réseau très chargé mine de rien.
Mais là, je te vois venir, tu vas me citer :
TCP
535653 segments reçus
893581 segments envoyés
1 segments retransmis
0 mauvais segments reçus
Tout se passe donc très bien pour mes gros flux. Mais pourquoi diable mon petit ping ne passe pas ??? Je ne comprend pas !
Et bien il s'agit là tout simplement d'une des caractéristiques essentielles qui font la différence entre TCP et ICMP + UDP.
TCP adapte son comportement en fonction du flux. Si le réseau est encombré alors il réduit ses émissions. ICMP et UDP non. Ils bourrinent. Donc si c'est bouché pouf paquet perdu. Il ne peux pas rentrer dans la carte réseau, elle n'a plus de place.
Je sais bien qu'il ne devrait plus y avoir de place pour TCP non plus, quand c'est plein c'est plein, mais là on rentre dans des modèles de statistique et de résonance. En gros, comme le flot TCP s'adapte à l'encombrement du réseau, cela produit un mécanisme de résonance, càd que tu vas avoir une période de saturation, ce que TCP le remarque, donc baisse du trafic, puis ah ça va mieux, on réémet, ah ca recoince, on rebaisse, ça va mieux etc.
Cela se met en place très rapidement dans ton cas puisque tu as une seule source et un seul récepteur. Comme ton flot UDP, en plus avec un ping t'as pas beaucoup de paquets émis, arrive de fait entre deux slaves TCP qui remplissent la mémoire de ta carte réseau, il n'a plus de place et se fait refouler d'office.
Je voulais te faire un graph avec les captures mais wireshark le fait très bien. Statistics > Flows graph me semble-t-il.
Enfin bref si tu as d'autres questions n'hésite pas.
Hors ligne
#13 Le 23/10/2007, à 09:33
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Merci c'est des infos en or que tu me donnes là !
2 raisons :
- Tu as une carte réseau pas très performante donc le processeur doit bosser beaucoup. D'ailleurs regarde son usage il doit monter à près de 100% non ?
- Tu as un processeur pas très puissant. Ça influe beaucoup sur un réseau très chargé mine de rien.
La carte réseau est intégrée à la carte mère, il y en a même 2, à 1 Gbps. Je vais vérifier les réf mais ce n'est pas de l'entrée de gamme (pas du serveur non plus). Je poste les refs dès que je les retrouve.
Pour le processeur, c'est un quad-core Q6600 ! Et en pleine période de perte de ping, il n'est pas très occupé. Aucun des core n'est à 100% (pas même à 50 % !!). En moyenne les 4 cores tournent à moins de 20% grand max !!!
Je précise quand même que je suis en 64 bits (Mais j'ai eu apparement le même phénomène sur un autre matériel en 32 bits).
Si je comprends bien ta démonstration, mon flux TCP (ldm/ssh) submerge le flux ICMP et c'est pour cela que les pings "tombent".
En situation de production, le ping ne m'intéresse pas tellement. C'est les services liés à PXE (DHCP et TFTP) qui sont critiquent et qui finissent par "tomber".
Comment faire pour conserver ces services actifs ?
Je suppose qu'une réponse trivial est d'utiliser un second serveur mais n'est-il pas possible de mieux gérer ce traffic afin que l'un n'étouffe pas l'autre ? QoS ? Est-ce simple à mettre en oeuvre ?
Merci en tout cas pour tes lumières.
Hors ligne
#14 Le 23/10/2007, à 13:51
- NP
Re : [Résolu] ping: sendmsg: no buffer space available
Sur les captures que tu m'as donné c'est du côté du client que c'est complètement coincé, pas sur le serveur. Il a lui aussi un Quad Core ? 
Généralement c'est TCP qui souffre du comportement d'UDP. Puisque le 1er s'adapte à la capacité du réseau, lorsqu'il voit que c'est encombré il diminue son trafic. UDP non, il continue d'émettre au maximum. Au final UDP écrase complètement TCP...
Chez toi UDP ne peux pas monopoliser le réseau puisqu'il est très minoritaire. TCP ne le voit pas, un ping c'est un paquet par seconde environ...
Si tu veux voir à l'oeuvre le comportement de TCP sur un réseau encombré tu peux générer beaucoup de trafic avec le ping. Dans un premier temps ils seront jetés, puis TCP va remarquer que le réseau est encombré et va réduire son trafic de plus en plus. Comme les ping ne vont jamais s'arrêter ils vont monopoliser tout ton réseau Et tu sera content d'avoir à nouveau tes ping qui fonctionnent
ping -i 0 192.168.250.95
un -i 0 demande à ce que tu émette aussi vite que possible. Cela va saturer complètement ton réseau alors évite de le faire dans ta boîte si les autres salariés travaillent 
et aussi prévient le gars qui à la machine 192.168.250.95 (si c'est bien le client) parce que face à l'émission qui va se prendre il risque de ramer pas mal le pauvre gars...
En ce qui concerne la QoS, c'est plus ou moins facile à mettre en place selon ce que tu veux faire et le matériel dont tu disposes.
Il y a plusieurs méthodes / technologies pour y arriver.
Là plus simple, que l'on oublie souvent, c'est de redimensionner ton réseau pour qu'il puisse absorber tout le trafic que tu génère.
Ah j'ai oublié de te demander une chose. Vu que c'est ton client qui à l'air saturé, si tu lance un PXE à partir d'un autre client est ce qu'il bloque également ? Le serveur Xcalib et PXE sont sur la machine machine ?
Si tu n'as pas beaucoup de ressources, un moyen simple pour faire de la QoS avec Linux est de passer par iptables. Tu pourras faire de la prioritisation de paquet mais vu ton architecture cela ne changera rien. lol. À moins de l'implanter sur tous tes clients. Ou, certainement plus utile pour toi, du traffic shapping. Ouch qu'est ce donc ???
C'est tout simplement limiter le débit en fonction du type de trafic. Tu peux réserver une partie de ta bande passante pour un type de service et une autre partie pour un autre type. Comme TCP s'adapte selon l'encombrement du réseau de bout en bout, si ton serveur limite son envoi, le client va réduire son émission aussi.
Comme ça tes flux pourront cohabiter tous ensemble. Elle est pas belle la vie
Bon après pour savoir quelle solution adopter il faut voir réellement ce que tu veux faire.
Hors ligne
#15 Le 23/10/2007, à 23:17
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Sur les captures que tu m'as donné c'est du côté du client que c'est complètement coincé, pas sur le serveur. Il a lui aussi un Quad Core ?
Le client est un Pentium D de moins de 2 ans.
Les captures que j'ai posté ont été réalisées côté serveur !!
Et c'est bien le serveur qui coince et pas le client. J'en veux pour preuve le test réalisé hier soir : J'ai introduit une troisième machine "neutre" qui faisaient des pings pendant que mon serveur et son client se parlaient fort. Les pings vers le client étaient corrects (<1ms) alors que les pings vers le serveur étaient en "Délai d'attente de la demande dépassé." (ma machine "neutre" est sous Windows 
)
Pour info, voici l'état de la CPU du serveur en "pleine charge" 
:
1 [|||||||||||| 25.5%] Tasks: 115 total, 1 running
2 [|||| 8.1%] Load average: 0.35 0.09 0.03
3 [||||| 9.3%] Uptime: 23:39:21
4 [|| 3.3%]
Mem[|||||||| 310/5471MB]Hors ligne
#16 Le 23/10/2007, à 23:25
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Ah j'ai oublié de te demander une chose. Vu que c'est ton client qui à l'air saturé, si tu lance un PXE à partir d'un autre client est ce qu'il bloque également ? Le serveur Xcalib et PXE sont sur la machine machine ?
Ce n'est pas le client qui sature (cf post précédent) et si je lance un autre client il a toutes les chances de ne pas booter en PXE ! (je vais refaire des tests pour confirmer ce point mais c'était mon constat initial et ce qui me gène le plus : pas moyen de démarrer en PXE un nouveau poste ou de rebooter un existant quand le serveur part "en caraffe").
C'est quoi Xcalib ?
Hors ligne
#17 Le 23/10/2007, à 23:44
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
L'idée du traffic shaping me plait bien (comme l'ensemble de ton explication d'ailleurs).
D'autant plus que le traffic est important ! En 1mn, l'interface réseau (eth0) crache environ 750 Mo en pleine charge.
J'ai activé la seconde interface réseau du serveur (eth1). Je n'ai aucun service actif sur cette interface. Pendant la minute de charge, elle n'a fait que répondre à des ping et devine quoi ...
... depuis ma troisième machine neutre, pendant cette minute de pleine charge :
- je pingue sans problème le client (<1ms)
- je ne pingue pas le serveur sur eth0 (timeout de 4s) : conforme à ce que j'attendais
- je ne pingue pas le serveur sur eth1 (timeout de 4s) : là je ne comprends plus !!
Jusqu'à présent, cela me dépassait, là je plane complètement !! 
Hors ligne
#18 Le 24/10/2007, à 03:56
- NP
Re : [Résolu] ping: sendmsg: no buffer space available
C'est quoi Xcalib ?
Là à 3heure du mat j'en sais rien, j'ai confondu avec Xaos... lol
depuis ma troisième machine neutre, pendant cette minute de pleine charge :
- je pingue sans problème le client (<1ms)
- je ne pingue pas le serveur sur eth0 (timeout de 4s) : conforme à ce que j'attendais
- je ne pingue pas le serveur sur eth1 (timeout de 4s) : là je ne comprends plus !!
Dans ce cas, c'est pas ton serveur qui a du mal, ni ton client mais la petite boiboite entre les deux... et oui c'est ton switch.
Pourquoi ?
Explication rapide, il faut que j'aille me coucher, j'ai mon premier cours demain. 
Ton switch est entre un réseau 1 Gb et 100 Mb ce qui fait 1000 Mb en entrée et 100 de l'autre... Les données qu'envoie ton serveur en 1 sec jusqu'à ton switch mettront 10 secondes à repartir jusqu'au client. Et c'est le switch qui fait le temporisateur entre les deux. C'est donc lui qui garde dans sa petite mémoire tous les paquets qu'il a reçu avant qu'il puisse les réexpédié. Dans ton cas il en a trop et cela sature sa file d'attente.
Si tu veux améliorer les choses baisse donc le débit de ta connexion 1 Gb à 100 Mb.
mii-tool -A eth0 --advertise 100baseTx-FDEst ce que cela ne va pas mieux ?
Si tu refais les pings comme tu les as fait dans ton post précédent ça devrai être bon.
À demain
Hors ligne
#19 Le 24/10/2007, à 22:53
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Quelques éléments en vrac ...
philippe@bergamotte:~$ sudo mii-tool
[sudo] password for philippe:
eth0: negotiated 100baseTx-FD flow-control, link ok
eth1: negotiated 100baseTx-FD flow-control, link okLes 2 interfaçes sont déjà négociées à 100 Mbps. L'une d'elle est pourtant relié à un port Gigabit et le switch confirme que le lien est bien du Gigabit et non pas du 100 Mbps !
D'ailleurs dmesg indique :
[ 46.510121] skge eth0: Link is up at 1000 Mbps, full duplex, flow control both
[82497.750074] sky2 eth1: Link is up at 100 Mbps, full duplex, flow control bothGoogle m'a parlé de ethtool ... du coup j'ai fait un :
philippe@bergamotte:~$ sudo ethtool -S eth0
NIC statistics:
tx_bytes: 21213328253
rx_bytes: 763164806
tx_broadcast: 184
rx_broadcast: 32968
tx_multicast: 71
rx_multicast: 421
tx_unicast: 15197896
rx_unicast: 7840680
tx_mac_pause: 0
rx_mac_pause: 1873088
collisions: 0
multi_collisions: 0
aborted: 0
late_collision: 0
fifo_underrun: 0
fifo_overflow: 0
rx_toolong: 0
rx_jabber: 0
rx_runt: 0
rx_too_long: 0
rx_fcs_error: 0C'est quoi ce rx_mac_pause ?
J'ai trouvé un post à ce sujet mais la discussion n'a pas abouti :
http://www.mail-archive.com/netdev@vger … 30596.html
J'ai aussi des infos avec 'ethtool -d eth0' mais je ne sais pas les interpréter
Pourquoi le traffic généré sur eth0 m'empêche de faire un ping sur eth1 ???
Si ma CPU n'est pas par terre, ce serveur DEVRAIT me répondre sur eth1 même si eth0 est saturé !
Le reste du réseau, y compris le client au bout de eth0, répondent normalement.
N'y-a-t-il pas une conf du noyau (une taille de cache, une limitation I/O) qui pourrait expliquer ce phénomène ??
Hors ligne
#20 Le 25/10/2007, à 01:38
- NP
Re : [Résolu] ping: sendmsg: no buffer space available
Il arrive que mii-tool ne puisse pas configurer les cartes mais c'est quand même très rare. Pas de bol
ethtool eth0 te dis également que tu es en 1 Gbits ?
Tu peux utiliser les 2 commandes suivantes pour passer en 100 Mbits
ethtool -s eth0 speed 100 duplex full autoneg off && ethtool -r eth0
ethtool eth0
En ce qui concerne les rx_mac_pause je suppose qu'il s'agit des trames que la carte reçoit de la part de son destinataire local, ici donc le routeur. Quand une carte réseau est saturé l'équipement envoi un trame à ses correspondants pour dire, hého pas si vite je ne peux pas reçevoir. Si vous continuez vous allez me saturer complètement et perdre des paquets (d'où aggravation de la saturation du réseau car réemission etc). Ce que l'on doit absolument éviter sinon le phénomène de saturation va s'amplifier. Je ne vois que cette signification possible.
Et cela me conforte d'avantage dans l'idée que c'est ton switch qui sature.
Tu peux peut-être voir l'utilisation de ses ressources s'il supporte le SNMP.
Autrement 2 solutions :
- Essaye absolument de passer ta carte en 100Mb avec ethtool comme décrit plus haut. Il n'y a pas de raison que cela ne fonctionne pas mais sinon on peux généralement le faire du côté du switch avec un bouton à régler 10 / 100 / 1000 Mb
- Change ton switch
D'ailleurs de quel modèle s'agit-il ?
Hors ligne
#21 Le 25/10/2007, à 08:52
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
Tu te couches tard ! J'espère que tes cours ne sont pas à 8h du mat
Je vais refaire les tests en branchant sur un port 100 Mbps.
Je vais aussi vérifier les modèles de switch. De mémoire il y a un Netgear 24x100+2x1000. J'ai au moins 2 autres marques pour tester (dont un SNMP).
Que se passerait-il à ton avis si j'utilise un cable croisé ? Le client va aussi "tomber" ?
Je vais aussi tester avec d'autres cartes réseau côté serveur. Celles intégrées utilisent les modules sky2 et skeg (donc des Marvell Yukon ?) et j'ai vu quelques posts relatant des problèmes.
Merci en tout cas pour ton aide.
Hors ligne
#22 Le 25/10/2007, à 15:55
- NP
Re : [Résolu] ping: sendmsg: no buffer space available
non lol les cours ne sont pas à 8H. Mais j'ai un peu de mal à me remettre dans le bain, hier était mon premier jour. Heureusement que cette année la fac de droit est plutôt cool. Du moins au début...
La différence entre un câble croisé et droit vient seulement de l'inversion de 2 fils à l'intérieur. Selon chacun tu peux ou pas relier tes équipements entre eux. Cette différence n'est quasiment plus utile puisque la majorité des switchs croisent ou décroisent pour que ça fonctionne.
Teste vraiment sur un port à 100, ça devrai aller beaucoup mieux. Mais de toute façon quel est ton but ? Parceque tu vas pouvoir lancer plus de Xandros mais ils font aussi finir par saturer ton réseau.
Merci en tout cas pour ton aide.
Mais il n'y a pas de problème, j'aime bien tout ce qui touche aux réseaux.
Si tu veux tu peux m'embaucher pour te filer un coup de main
Hors ligne
#23 Le 27/10/2007, à 23:46
- PhENTZ
Re : [Résolu] ping: sendmsg: no buffer space available
non lol les cours ne sont pas à 8H. Mais j'ai un peu de mal à me remettre dans le bain, hier était mon premier jour. Heureusement que cette année la fac de droit est plutôt cool. Du moins au début...
Fac de droit ... compétences réseau ... T'es sûr d'être dans la bonne voie ?
Sinon ca y est j'ai trouvé une solution !!!
J'ai suivi ta piste de "traffic shaping". Après quelques recherches google et 3 commandes tc plus loin, je pingue bien mon serveur dans tous les cas de figure.
Je n'ai pas tout pigé dans htb et tc mais globalement je crois que j'ai réussi à contenir mon traffic TCP et éviter du coup de perdre mes ping ;-) Je vais pouvoir tester dès demain si cette config en situation réelle permet enfin à mes client PXE de booter quelque soit la charge réseau du serveur.
Merci du coup de main !
Si tu veux tu peux m'embaucher pour te filer un coup de main smile
Je te contacte par mail.
Hors ligne
#24 Le 28/10/2007, à 22:08
- NP
Re : [Résolu] ping: sendmsg: no buffer space available
Fac de droit ... compétences réseau ... T'es sûr d'être dans la bonne voie ?
lol oui j'ai fait aussi un Master informatique et réseaux, c'est pour ça. Mais comme je souhaites avoir une double compétence Droit et Informatique j'ai bifurqué dans ce domaine cette année. Je ne le regrette pas du tout, c'est très enrichissant pour l'instant même si je n'ai pas encore eu beaucoup de cours.
En tout cas si tu veux d'autres conseils n'hésites pas. Que donnes tes tests en situation réelle ?
PS : J'avais cru comprendre que tc était moins souple qu'iptables pour faire du trafic sharping. Mais bon de toute façon comme tu n'as pas beaucoup de flux c'est pas très important pour toi. L'essentiel étant que cela fonctionne
Hors ligne
#25 Le 31/10/2007, à 03:10
- dsur
Re : [Résolu] ping: sendmsg: no buffer space available
Les cartes Marvell, dont le driver skge / sky2 etc pour linux ne sont pas stables sous fortes charges.
Elles perdent des trames UDP sans raisons apparentes.
Ce n'est pas du haut de gamme, une puce intégrée pas cher.
Avec un tel matériel, une carte PCI Express 1x / PCI-X 64bits ne sera pas une ruine et sera bien plus adapté et stable, si tu prend par exemple du Intel ou 3COM.
Pour information, ces Marvells même sous windows produisent de gigantesque latence interne d'ordre de 100 us sans traffic réseau ! On dirait que c'est une mauvaise programmation des DPC, produisant un lag de tous les autres périphériques en attente... Tout cela même en réduisant fortement les interruptions de la carte et la soit disant "accélération checksum".
Bref, ce n'est peut-être pas le cas de toute carte mère ayant du Marvell intégré, mais méfiance...
Bonne chance
Hors ligne
Pages : 1