SMB ha affermato di essere "lenta"

La nostra rete aziendale (che credo sia un dominio Windows eseguito sul server 2008) è dolorosamente lenta. Un esempio lampante di ciò è la copia di file su SMB: gli elenchi richiedono minuti e la copia di file anche di dimensioni modeste richiede ancora più tempo. Quando viene affrontato il problema, il responsabile IT (che, nonostante qualsiasi altro merito possa avere, è una persona molto testarda e non molto tecnica) alza le mani, diventa molto difensivo e dà scuse invece di ascoltare e tentare di elaborare la causa principale del problema.

Ora, riconoscendo che l'elemento umano di questo problema richiederà del tempo e degli sforzi per risolverlo, non mi resta che sapere come confutare tecnicamente le sue scuse. In questo caso, afferma che SMB è il problema e che è un protocollo "lento". Ci sono prove per questa affermazione (ho solo contro prove aneddotiche)? Qual è il modo migliore per fare progressi in questo argomento?

SMB potrebbe essere più lento di altri protocolli di condivisione di file e potrebbe essere più veloce di altri. Ma questa non è la parte importante.

Invece di fare questa domanda / argomento, puoi trovare un modo per passare da quello e chiedere se SMB è più veloce (o più lento!) Come dovrebbe essere. Ad esempio, è possibile trasferire un file tramite FTP tra il server e una workstation che soffre della lentezza e vedere un marcato salto di prestazioni?

Il fornitore potrebbe essere in grado di indicarti le recensioni sull'hardware, con Windows installato, che parlano delle prestazioni del file server.

Nella mia esperienza, SMB è più che "abbastanza veloce" sulla mia rete. Stiamo gestendo una rete da 10 Gb tra i server e siamo molto soddisfatti delle prestazioni del file server tramite SMB e abbiamo misurato salti di buone prestazioni sullo stesso hardware a seconda che utilizziamo la scheda di rete da 1 Gb o 10 Gb. SMB non è un problema per noi.

Guarderei sicuramente altre cose sulla tua rete: l'infrastruttura è obsoleta, è configurata in modo ottimale (ad esempio le schede di rete del server sono tutte configurate correttamente per i driver più recenti, funzionano correttamente alla migliore velocità possibile), sono cose come DNS e così- su tutto configurato correttamente, c'è un sacco di traffico "spazzatura" sulla rete che causa un rallentamento, l'antivirus è configurato in modo eccessivamente paranoico (ho visto che ciò causa alcuni rallentamenti scioccanti ).

C'è molto che può causare cattive prestazioni del file server e molto poco è la scelta del protocollo.

Sebbene esistano protocolli più veloci di SMB, non è affatto intrinsecamente lento.

È tuttavia forse un po 'più suscettibile alle influenze esterne rispetto ad altri protocolli, ad esempio server saturi, segmenti saturi ecc.

Se fossi un giocatore d'azzardo, sospetterei che la tua rete potrebbe avere a che fare con una riprogettazione o un investimento poiché molte reti di uffici regolari di società non sono state aggiornate per tenere conto dell'enorme aumento del traffico Internet e Intranet osservato negli ultimi anni. Inoltre, c'è una ragionevole possibilità che il / i server / i potrebbe essere necessario sostituire o rielaborare per ottenere il meglio da essi.

In entrambi i casi non vorrei porre troppa enfasi sul fatto che SMB sia il colpevole diretto, è più che probabile che sia solo il fallito per il cattivo / vecchio network e kit server.

Ha più overhead (per il trasferimento) di cose come NFS o FTP. L'elenco dei file di directory di grandi dimensioni può richiedere del tempo: alcuni di questi sono dovuti a SMB, alcuni a causa di NTFS, altri a causa di cose stupide che le varie versioni di Explorer e il software installato possono fare dal client. Alcune cose come i database basati su file (Access, file PST) non dovrebbero essere aperti su collegamenti lenti (WAN) perché non gestiscono bene la latenza.

Detto questo, le operazioni che descrivi non dovrebbero richiedere molto tempo. Forse il fileserver (s?) È / sono sottodimensionato. Forse la società ha alcuni software come parte dell'installazione standard che rallenta le cose. Forse c'è uno scanner antivirus configurato male. Forse c'è un virus. Forse c'è un collegamento WAN che non conosci tra te e il server.

1. Elencare i file è più veloce se lo fai da una riga di comando anziché da Explorer?
2. Che ne dici di copiare?
3. Esegui il ping del server in questione dal desktop: qual è la latenza?
4. Effettua un traceroute: quanti hop ci sono tra te e il server?

Sfortunatamente Nate, non possiamo occuparci direttamente dei PHB. La tua prima linea di difesa qui sono le metriche effettive, come ad esempio i confronti tra trasferimento SMB e NFS, ad esempio.

Una volta che hai numeri o statistiche reali a sostegno dei tuoi argomenti, non dovrai più occuparti dell'elemento umano. Le statistiche dicono "qui è dove si trova il problema, ed ecco la prova". Questa è la tua discussione.

Puoi restringerlo del tutto? Un trasferimento da server a server sulla stessa sottorete ha risultati migliori? Che ne dici di trasferire da un client all'altro ( \\client\c$→ \\client\d$)?

Potresti trovare qualcosa di semplice come la mancata corrispondenza duplex.

So che questo è vecchio, ma un fattore molto importante da prendere in considerazione è l'I / O del disco. Se le prestazioni di scrittura su disco sono incredibilmente lente a causa del RAID software / scheda madre rispetto a una scheda RAID basata su hardware con memoria dedicata.

Il carico di rete è un fattore, ma la cosa migliore da fare come amministratore di sistema è guardare Resource Monitor e ispezionare da dove potrebbero provenire i colli di bottiglia: ispezionare la scheda Panoramica per mostrare CPU, rete, I / O del disco, memoria, ecc. Da questo vantaggio, è possibile vedere se esiste un processo o un insieme di processi colpevoli che si esauriscono in I / O su disco o una perdita di memoria (SQLServer.exe - istanza SBSMonitoring), ecc. Se esiste un processo di rete che utilizza molti larghezza di banda, controlla quel processo e controlla quanti e quali host sono collegati a quel processo. Potrebbero essere molti i tentativi di hacking di RDP su 3389. L'ho già visto in precedenza e la nostra soluzione era rimuovere l'accesso diretto RDP e spostare gli utenti remoti finali su VPN.

Spero che sia di aiuto!