[RESOLU] DL ultra-lent, de clients Windows XP "vers" serveur Samba

DL ultra-lent, de clients Windows XP "vers" serveur Samba [RESOLU] - Réseaux - Systèmes & Réseaux Pro

Marsh Posté le 30-05-2008 à 17:32:53    

Bonjour à tous !
 
Une petite énigme à vous soumettre, sur laquelle je me suis cassé la tête sans pouvoir la résoudre (pour l'instant)...
 
Contexte
Réseau local composé d'un serveur de domaine / fichiers sous Linux Debian Etch (tout à jour, installation minimale effectuée à partir de netinstall, puis ajout des paquets utiles) et deux postes de travail clients.
"client1" est un ordinateur portable (équipé en WiFi) sous Windows XP Pro SP3, qui ouvre une session dans le domaine. "client2", sous Windows XP Home SP2, se contente d'accéder aux partages SAMBA du serveur de fichiers (sans ouverture de session, puisque XP Familial)
Le tout est connecté en filaire (câbles Gigabit, mais Livebox Pro à 100 Mbits).
 
L'ouverture de session dans le domaine ajoute des lecteurs réseau dans le Poste de Travail des clients (via un batch stocké sur le serveur, exécuté en local à l'ouverture de session).
 
 
Problème
Le truc, c'est que je constate un débit ridicule (150 ko/s environ, fluctuant de 70-80 à 300 ko/s), uniquement dans le sens serveur vers client1 (copie de 50 Mo d'un ensemble de fichiers de 700 ko en moyenne , d'un lecteur réseau du client1, vers un dossier en local). Dans l'autre sens (copie de fichiers vers le lecteur réseau), le débit est conforme à ce qu'on peut attendre d'un réseau Ethernet 100 Mbits (7 Mo/s).
 
Le même test entre client1 et client2 montre aussi des débits dans la norme. Idem quand le test est fait entre serveur et client2 (à revérifier, parce que je suis soudain pris d'un doute).
 
Côté Livebox, j'ai changé de prise Ethernet le câble reliant celle-ci à poste 1 : peine perdue, le débit reste ridicule dans le sens serveur vers client1.
Curieusement, le problème continue à se poser même lorsque je change d'interface réseau pour basculer vers le WiFi (client1 est un portable équipé en WiFi Intel 4965N) : les débits restent comparables à ceux obtenus en filaire.
Même chose lorsque le poste est démarré en "mode sans échec avec prise en charge du réseau".
 
Je suis un peu paumé, là. On dirait que le problème vient du serveur... mais de quoi s'agit-il, sachant qu'il n'y a pas encore de pare-feu sur ce serveur ? Pour info, le redémarrage du serveur ne change rien au problème.
 
Alors, même si vous n'avez pas de solution toute prête à fournir, je suis preneur de toute question, toute suggestion et tout test qui pourrait faire avancer le débat. Merci d'avance !


Message édité par agyar le 09-06-2008 à 22:10:10
Reply

Marsh Posté le 30-05-2008 à 17:32:53   

Reply

Marsh Posté le 02-06-2008 à 02:40:08    

question : as-tu essayé de copier une ISO pour voir ce que ca donne avec un seul gros fichier ?
de faire le même test en remplacant la copie windows par du FTP ?

 

sinon, en quoi ce problème est-t-il un problème pro ?


Message édité par trictrac le 02-06-2008 à 02:40:35
Reply

Marsh Posté le 05-06-2008 à 22:42:09    

Bonjour, et merci pour la réponse.
 
Pour répondre à ta dernière question : sauf si je comprends mal le terme "pro", c'est un problème "pro" parce que :
- Je suis professionnel (enfin, j'essaie...), en assistance informatique sur site
- Le réseau est un réseau d'entreprise. Pas grosse (2 postes, 4 ou 5 à moyen terme), mais quand même.
Maintenant, si je me suis trompé de thread, ça peut peut-être s'arranger (mais je ne sais pas comment).
 
Pour répondre aux autres questions : en bref, non, je n'ai pas fait les tests que tu suggères.
En revanche, j'en ai fait d'autres, qui à mon sens rendent sans objet les tests proposés. Voici, en résumé, la situation actuelle :
- Le problème ne vient pas de la Livebox. Testé avec un autre matériel (routeur-modem Netgear), avec les mêmes résultats.
- Le problème ne vient pas du support de connexion (câbles Ethernet) : testé avec d'autres câbles, ou en Wifi, le résultat est invariable.
- Le problème ne vient pas d'un pare-feu ou d'un antivirus : le serveur n'a pas de pare-feu, et le problème se pose toujours quel que soit le pare-feu (celui intégré à XP ou celui de Kaspersky) ou si l'antivirus est absent.
 
Le problème se situe donc au niveau du serveur et/ou au niveau des clients.
J'ai intégré aujourd'hui un deuxième poste (fixe) au domaine, basé sur une installation de Windows similaire à celle du premier poste, et ai reproduit le même comportement : vitesse de transfert normale pour la copie de fichiers du poste client vers les partages réseau du serveur, vitesse de transfert incroyablement basse dans l'autre sens (lorsque le client récupère des données sur le serveur).
 
J'ai tenté de "pousser" les fichiers à partir du serveur, en me connectant à un dossier partagé sur le client (via smbclient). La vitesse de transfert est normale dans ce cas de figure (6 Mo/s environ sur des fichiers de 700 ko en moyenne).
Même chose lorsque je "tire" les fichiers à partir d'une station sous Linux (Ubuntu), sur laquelle j'accède aux partages Samba du serveur : vitesse de transfert normale.
J'ai également confirmé aujourd'hui que la vitesse de transfert est normale lorsque le transfert est effectué directement entre les deux postes.
 
Je soupçonne de plus en plus Samba de me jouer un vilain tour, mais ne comprend toujours pas d'où vient le souci. En réalité, je me demande s'il n'y a pas une espèce d'incompatibilité entre les clients et le serveur ?
 
A tout hasard, je poste le fichier de configuration de Samba (en dégageant la plupart des commentaires, histoire de compacter un peu le bousin) :

Code :
  1. # Global parameters
  2. [global]
  3.     # GESTION DU RESEAU
  4.     workgroup = SOCIETE
  5.     netbios name = PANORAMIX
  6.     server string = Serveur Samba (Debian GNU/Linux)
  7.     security = User
  8.     hosts allow = 192.168.1.1/255.255.255.0 127.0.0.1
  9.     domain logons = Yes
  10.     domain master = Yes
  11.     preferred master = Yes
  12.     local master = Yes
  13.     wins support = Yes
  14.     dns proxy = No
  15.     name resolve order = wins host lmhosts bcast
  16.     # GESTION DES UTILISATEURS
  17.     logon home = \\%L\profiles\%U
  18.     logon script = %U.bat
  19.     add user script = /usr/sbin/useradd -d /dev/null -g machines -c 'Machine Account' -s /bin/false -M %u
  20.     # MOTS DE PASSE
  21.     encrypt passwords = true
  22.     smb passwd file = /etc/samba/smbpasswd
  23.     unix password sync = Yes
  24.     passwd program = /usr/bin/passwd %u
  25.     passwd chat = *Enter\snew\sUNIX\spassword : * %n\n *Retype\snew\sUNIX\spassword : * %n\n *passwd:*all*authentication*tokens*updated*successfully*
  26.     # DIVERS
  27.     time server = Yes
  28.     os level = 64
  29.     log file = /var/log/samba/log.%m
  30.     max log size = 500
  31.     socket options = IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
  32.     # IMPRIMANTES
  33.     printcap name = cups
  34.     printing = cups
  35.     # Respect des noms de fichier et de leur casse
  36.     preserve case = Yes
  37.     short preserve case = Yes
  38. # TOUS LES PARTAGES
  39. # Repertoire des scripts de connexion et droits d'acces
  40. [netlogon]
  41.         comment = Scripts de connexion reseau
  42.         path = /home/VAR-samba/netlogon
  43.         public = No
  44.         writeable = No
  45.         browseable = No
  46. # Partage necessaire pour stocker les profils utilisateurs Windows (NT4/2k/XP)
  47. [profiles]
  48.         path = /home/VAR-samba/profiles
  49.         read only = No
  50.         browseable = No
  51. #        hide files = /desktop.ini/Desktop.ini/ntuser.ini/NTUSER.*/
  52. # Repertoires personnels
  53. [homes]
  54.         comment = Repertoires personnels
  55.         read only = No
  56.         create mask = 0770
  57.         directory mask = 0770
  58.         browseable = No
  59. # Partages communs
  60. [Commun]
  61.         comment = Dossier commun
  62.         path = /home/commun
  63.         create mask = 0770
  64.         directory mask = 0770
  65.         read only = No
  66.         guest ok = No
  67.         browseable = No
  68.         write list = @direction
  69. [Gestion]
  70.         comment = Dossier des fichiers de gestion
  71.         path = /home/gestion
  72.         create mask = 0770
  73.         directory mask = 0770
  74.         read only = No
  75.         guest ok = No
  76.         browseable = No
  77.         write list = @gestion


Voilà... Moi, je sèche complètement pour ce soir. Mais je crois que je vais rapidement devoir apprendre à me servir de Wireshark...
 
Encore une fois, merci à tous ceux qui auront eu la patience de me lire, et encore plus à ceux qui auraient la gentillesse de répondre !


Message édité par agyar le 05-06-2008 à 22:44:11
Reply

Marsh Posté le 06-06-2008 à 00:25:55    

TU dis que les tests que tu as faits rendent inutiles les tests qu'on te propose plus haut mais je suit totalement persuadé que non...
Trictrac te demandais à juste titre de tester avec un autre protocole... et c'est un test interessant...
Tes test se résument à des copies de fichiers... mais c'est totalement insufisant...
 
Quand on souhaite résoudre un probleme réseau, basé sur TCP/IP on commence par remonter une par une les couches...
 
Commence tout d'abord par tester iperf dans les deux sens client et serveurs entre ton serveur et tes clients...
Dejà si tu valide que la vitesse est correcte, c'st bien au niveau de la couche application qu'il faut chercher...
 
Test avec d'autres protocoles, FTP, NFS, CIFS
 
De toute facon c'est cousu de fil blanc, SAMBA n'est autre qu'un protocole qui essaye tant bien que mal de communiquer avec les protocoles FERMES et Propriétaire que sont CIFS et SMB
D'ailleurs tes montages réseau sont explorté en smb ou cifs?  
 
Pour finir qu'elle est la version de Samba que tu utilise? compile la derniere  version, les avancées dans ce domaine sont souvent nombreuses

Reply

Marsh Posté le 06-06-2008 à 02:58:05    

Merci pour ton avis, bartounet16.
 
OK pour le "totalement insuffisant". Je mentirais si je disais que je suis complètement d'accord, vu que le problème se pose :
- dans un sens (serveur vers client),
- lorsque le transfert est initié par le client,
- lorsque le client est sous Windows XP,
- lors de l'accès aux partages Samba (tous les partages).
 
Formulé autrement, le problème ne se pose pas :
- lorsque le transfert s'effectue du client vers le serveur, à l'initiative du client ou du serveur,
- lorsque le transfert s'effectue dans le sens qui pose problème, mais depuis un poste sous Linux (j'avoue, je sais pas si le partage est CIFS ou SMB dans ce cas),
- lorsque le transfert s'effectue entre deux clients du domaine.
 
Compte tenu de ce qui précède, il n'est pas certes pas exclu que le problème se situe à un autre niveau que celui de l'interaction Samba / Windows.
Mais vu que les transferts de fichiers se font normalement entre le serveur et un client Linux, j'ai tendance à penser qu'il s'agit bien d'un souci propre à l'interaction Samba/Windows.
 
bartounet16 > Tu parles de "remonter les couches". J'imagine que c'est juste une expression, parce que sauf erreur de ma part, FTP, NFS, CIFS, SMB, même combat : c'est la couche 7 du modèle OSI.
 
Je vais déjà tester avec iperf (merci, je connaissais pas) et, éventuellement, FTP.
Comme j'ai un gros doute, je vais aussi re-tester le transfert de fichier entre le serveur et un poste non intégré dans le domaine.
 
Pour le type des montages réseau, j'avoue ne pas savoir comment trouver quel protocole est utilisé ?! J'imagine que c'est SMB, celui-ci ayant supplanté CIFS depuis pas mal de temps apparemment, mais comment vérifier ?
 
Version de Samba utilisée : 3.0.24-6etch9 (le paquet samba récupéré par apt-get, quoi). Ta suggestion d'utiliser la dernière version stable de Samba semble effectivement pleine de sens, je vais voir ça.
(En même temps, j'ai exactement la même version sur un serveur de fichiers à l'atelier, et j'ai aucun problème avec les clients sous Windows !? Le smb.conf du serveur du cas qui m'intéresse vient assez directement de celui en place à l'atelier, bref c'est vraiment curieux cette histoire).
 
Bref, il est temps d'aller se coucher : la nuit porte conseil, paraît-il. Au menu des prochains jours : iperf, wireshark et FTP. Miam !


Message édité par agyar le 08-06-2008 à 22:06:20
Reply

Marsh Posté le 08-06-2008 à 21:55:35    

Bonjour à nouveau,
 
Résultat des courses : problème toujours pas résolu.
 
Les derniers tests :
- FTP client au moyen de FileZilla (Portable) depuis les postes sous XP : débit moyen en DL de 1,4 Mo/s. Ce serait en WiFi, ce serait pas un mauvais score :/. Débit en upload : environ 9 Mo/s.
- FTP client en ligne de commande depuis un poste sous Ubuntu : vitesses de transfert normales (environ 9,5 Mo/s dans les deux sens).
- iperf TCP : lorsque la machine Linux est le serveur, perfs mauvaises pour les clients XP : 14 Mbits/s. Dans l'autre sens (iperf serveur sous XP, client Linux), pas de souci (94 Mbits/s). Pas de problème relevé quand le client est Ubuntu, ou même entre les deux postes XP.
- iperf UDP : perfs nazes quel que soit le sens (1.05 Mbits/s). Ça m'a drôlement perturbé d'abord, et puis j'ai constaté que le comportement était le même à l'atelier, alors que je ne rencontre aucnu problème de réseau. Je ne vois pas où est le problème (Interface Chaise-Clavier ?), mais a priori cela n'a pas de rapport avec le souci qui m'occupe.
- Même topo (lenteur FTP/Samba en DL) depuis un poste Win XP SP2 non intégré au domaine.
 
Merci BEAUCOUP pour vos conseils, messieurs : je me plantais. Il y a bien un problème avec TCP, dans le sens XP vers Linux. Les performances minables (quelques ko/s) en lecture des partages Samba sont sûrement - je l'espère - à mettre sur le dos de ce souci.
En revanche, vu que le problème ne se pose pas depuis un client Ubuntu, à quel niveau situer le problème ?!
J'ai trouvé - vraiment par hasard - cette page, qu'il faut que je relise pour m'en imprégner, mais qui mentionne - dans certains cas pas vraiment éclaircis - un problème entre le protocole TCP d'un serveur Linux et la couche Winsock2 de postes Windows.
 
Prochaines actions :
- Rénitialiser la pile tcp et le catalogue winsock des postes Windows (?)
- Ajouter une carte Ethernet PCI au serveur, désactiver la carte réseau intégrée et refaire les tests sur cette nouvelle interface.


Message édité par agyar le 09-06-2008 à 03:34:05
Reply

Marsh Posté le 09-06-2008 à 22:09:50    

Le mot de la fin : c'est en fait un problème de pilote : le module (r8169) qui gère le chipset réseau intégré à la carte mère (Realtek RTL8111B ??) semble bien avoir un problème pour faire son boulot correctement dans ce cas de figure.
 
J'ai réglé la question en ajoutant une carte Ethernet sur un port PCI, et en faisant transiter le réseau par celle-ci : tout fonctionne parfaitement à présent. Bien que le chipset emplyé soit toujours du Realtek, c'est un autre module (8139too) qui gère la carte.


Message édité par agyar le 09-06-2008 à 22:14:01
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed