SMB prétend être «lente»


8

Notre réseau d'entreprise (qui, je crois, est un domaine Windows exécuté sur le serveur 2008) est douloureusement lent. Un bon exemple de cela est la copie de fichiers sur SMB - les listes prennent quelques minutes, et la copie de fichiers même de taille modeste prend encore plus de temps. Lorsqu'il est approché à propos de la question, le responsable informatique (qui, malgré tous les autres mérites qu'il pourrait avoir, est une personne très têtue et pas très technique) lève les mains, devient très défensif et donne des excuses au lieu d'écouter et d'essayer de déterminer la cause profonde du problème.

Maintenant, reconnaissant que l'élément humain de ce problème prendra du temps et des efforts à résoudre, je ne sais pas trop comment réfuter techniquement ses excuses. Dans ce cas, il affirme que SMB est le problème et qu'il s'agit d'un protocole "lent". Y a-t-il des preuves de cette déclaration (je n'ai que des contre-preuves anecdotiques)? Quelle est la meilleure façon de progresser dans cet argument?


Quel type de réseautage est en place? gigabit? 100 megabit? Copiez-vous des fichiers sur un LAN ou un WAN / VPN? Avez-vous un domaine Windows ou un groupe de travail Windows? J'ai vu un groupe de travail provoquer des ralentissements comme ça. Pouvez-vous transférer des fichiers FTP plus rapidement que le partage réseau? SMB est généralement considéré comme un protocole qui n'est pas très efficace par rapport aux autres protocoles.
Nate

@Nate Bross - 100meg, LAN, domaine.
Nate

2
Toutes les listes de répertoires ne prennent que quelques minutes ou les listes de répertoires contenant des milliers de fichiers prennent-elles quelques minutes?
Skyhawk

@Miles Erickson - Toutes les listes peuvent prendre quelques minutes. Parfois, ce sera très rapide, mais essayer fréquemment d'accéder aux partages réseau bloque l'explorateur pendant quelques minutes.
Nate

3
Le responsable informatique n'est pas très technique? Est-ce juste moi ou quelqu'un d'autre y voit-il un problème?
Alan B

Réponses:


14

SMB pourrait bien être plus lent que certains autres protocoles de partage de fichiers, et il pourrait bien être plus rapide que d'autres. Mais ce n'est pas la partie importante.

Au lieu d'en faire la question / l'argument, pouvez-vous trouver un moyen de passer à autre chose et de demander si SMB est aussi rapide (ou aussi lent!) Qu'il est censé l' être. Par exemple, pouvez-vous transférer un fichier via FTP entre le serveur et un poste de travail qui souffre de la lenteur et voir une nette augmentation des performances?

Le fournisseur peut vous indiquer des avis sur le matériel, avec Windows installé, qui parlent des performances du serveur de fichiers.

D'après mon expérience, SMB est plus que "assez rapide" sur mon réseau. Nous exécutons un réseau de 10 Go entre les serveurs et nous sommes très satisfaits des performances du serveur de fichiers à l'aide de SMB et nous avons mesuré de bons sauts de performances sur le même matériel selon que nous utilisons la carte réseau 1 Go ou 10 Go. SMB n'est pas un problème pour nous.

Je regarderais certainement d'autres choses sur votre réseau - l'infrastructure est-elle obsolète, est-elle configurée de manière optimale (par exemple, les cartes réseau du serveur sont toutes configurées correctement pour les derniers pilotes, fonctionnant correctement à la meilleure vitesse possible), sont des choses comme DNS et ainsi de suite - sur tout correctement configuré, y a-t-il beaucoup de trafic "indésirable" sur le réseau provoquant un ralentissement, l'antivirus est-il configuré de manière trop paranoïaque (j'ai vu cela provoquer des ralentissements choquants ).

Il y a beaucoup de choses qui peuvent entraîner de mauvaises performances du serveur de fichiers et très peu d'entre elles sont le choix du protocole.


4
Après avoir parlé avec notre administrateur système, il a fait un test où il a supprimé l'antivirus, et la vitesse a flambé. Bonne suggestion!
Nate

2
+1 pour DNS. Les erreurs de configuration DNS qui entraînent des délais d'attente auront un impact énorme sur les performances.
duffbeer703

10

Bien qu'il existe des protocoles plus rapides que SMB, il n'est en aucun cas lent par nature.

Il est cependant peut-être un peu plus sensible aux influences extérieures que les autres protocoles, ceux-ci étant des serveurs saturés, des segments saturés etc.

Si j'étais un joueur de jeu, je soupçonnerais que votre réseau pourrait faire l'objet d'une refonte ou d'un investissement, car les réseaux de bureaux réguliers de nombreuses entreprises n'ont pas été mis à niveau pour tenir compte de l'énorme augmentation du trafic Internet et intranet observée ces dernières années. Il y a également une chance raisonnable que le ou les serveurs aient besoin d'être remplacés ou retravaillés pour en tirer le meilleur parti.

Quoi qu'il en soit, je ne mettrais pas trop l'accent sur le fait que SMB soit le coupable direct, il est plus que probable que ce soit le coupable des mauvais / vieux réseaux et kits de serveurs.


1
+1 - Le protocole SMB d'origine (pas SMBv2) craint comme un Hoover sur des liaisons à latence élevée. Avec des latences LAN typiques (millisecondes à un chiffre ou moins), cela fonctionne très bien. Si l'OP ne suit pas le trafic et les erreurs sur les ports de commutation, ce serait le bon moment pour commencer. Mon instinct dit qu'une discordance duplex est quelque part dans ce problème.
Evan Anderson

1
@evan, mon instinct dit que c'est un serveur dual-core 1 Go double disque de sept ans avec une seule carte réseau de
100 Mo

Il est tout à fait possible, même si une boîte comme celle-ci ne devrait pas prendre quelques minutes pour renvoyer des listes de répertoires dans la plupart des circonstances.
Evan Anderson

@evan, pourrait être un système de fichiers corrompu, je suppose ... @nate, pourriez-vous tester votre réseau en partageant un répertoire sur une machine en le parcourant depuis une autre?
Chopper3

Il peut s'agir du port sur lequel le serveur lui-même est branché. Regarder les taux d'erreur de ce port (les erreurs de collision tardive étant un excellent indicateur de non-concordance de duplex) et tester d'autres types de trafic vers / depuis ce serveur (l'utilitaire "WSTTCP" fonctionne bien pour mesurer le débit TCP brut du NIC / driver sous Windows) sont probablement les deux idée de marchandises. La surveillance de base des performances sur le serveur affecté est également une bonne idée: surveiller l'utilisation du processeur, de la RAM, du réseau et des E / S.
Evan Anderson

2

Il a plus de frais généraux (pour le transfert) que des choses comme NFS ou FTP. La liste des fichiers de grands répertoires peut prendre un certain temps - en partie à cause de SMB, à cause de NTFS, à cause de choses stupides que les différentes versions d'Explorer et les logiciels installés peuvent faire du côté client. Certaines choses comme les bases de données basées sur des fichiers (fichiers Access, PST) ne doivent pas être ouvertes sur des liaisons lentes (WAN) car elles ne gèrent pas bien la latence.

Cela dit, les opérations que vous décrivez ne devraient pas prendre beaucoup de temps. Peut-être que le ou les serveurs de fichiers sont / sont sous-alimentés. Peut-être que la société a un logiciel dans le cadre de l'installation standard qui ralentit les choses. Il y a peut-être un scanner de virus mal configuré. Peut-être qu'il y a un virus. Il existe peut-être un lien WAN que vous ne connaissez pas entre vous et le serveur.

  1. La liste des fichiers est-elle plus rapide si vous le faites à partir d'une ligne de commande au lieu d'Explorer?
  2. Que diriez-vous de copier?
  3. Envoyez une requête ping au serveur en question depuis votre bureau - quelle est la latence?
  4. Faites un traceroute - combien de sauts séparez-vous du serveur?

2

Malheureusement Nate, nous ne pouvons pas traiter directement avec les PHB. Votre première ligne de défense ici est des mesures réelles, comme dans le cas des comparaisons entre le transfert SMB et NFS, par exemple.

Une fois que vous avez des chiffres ou des statistiques réels pour étayer vos arguments, vous n'aurez plus à vous soucier de l'élément humain. Les statistiques disent "c'est là que se situe le problème, et voici la preuve". Voilà votre argument.


1
Eh bien, c'est ce que je demande - quelles sont les statistiques que je dois collecter? Comment puis-je les récupérer?
Nate

0

Pouvez-vous le réduire du tout? Un transfert de serveur à serveur sur le même sous-réseau a-t-il de meilleurs résultats? Que diriez-vous d'un transfert d'un client à un autre ( \\client\c$\\client\d$)?

Vous pouvez trouver quelque chose d'aussi simple qu'une asymétrie duplex.


0

Je sais que c'est ancien, mais un facteur très important à prendre en considération est les E / S disque. Si les performances d'écriture du disque sont incroyablement lentes en raison du RAID logiciel / carte mère par opposition à une carte RAID matérielle avec mémoire dédiée.

La charge réseau est un facteur, mais la meilleure chose à faire en tant qu'administrateur système est de regarder le moniteur de ressources et d'inspecter l'origine des goulots d'étranglement - en inspectant l'onglet Présentation pour afficher l'ensemble du processeur, du réseau, des E / S disque, de la mémoire, etc. De cette vue, vous pouvez voir s’il existe un processus coupable ou un ensemble de processus qui rongent les E / S disque, ou une fuite de mémoire (SQLServer.exe - instance SBSMonitoring), etc. S'il existe un processus réseau utilisant beaucoup de bande passante, vérifiez ce processus et inspectez le nombre et les hôtes liés à ce processus. Cela pourrait être beaucoup de tentatives de piratage pour RDP sur 3389. J'ai déjà vu cela comme le cas et notre solution était de supprimer l'accès direct RDP et de déplacer les utilisateurs distants finaux vers VPN.

J'espère que cela t'aides!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.