SMB afirmou ser “lento”

Question

A rede da nossa empresa (que acredito ser um domínio do Windows executado no servidor 2008) é dolorosamente lenta. Um excelente exemplo disso é copiar arquivos em SMBs - as listagens levam minutos, e copiar até mesmo arquivos de tamanho modesto leva mais tempo. Quando abordado sobre o assunto, o gerente de TI (que, apesar de quaisquer outros méritos que ele possa ter, é uma pessoa muito teimosa e não muito técnica) levanta as mãos, torna-se muito defensivo e dá desculpas em vez de ouvir e tentar descobrir a causa raiz do problema.

Agora, reconhecendo que o elemento humano desse problema levará algum tempo e esforço para resolver, fico sem saber exatamente como tecnicamente refutar suas desculpas. Nesse caso, ele afirma que o SMB é o problema e que é um protocolo "lento". Existe alguma evidência para esta afirmação (tenho apenas contra-indicações)? Qual é a melhor maneira de avançar neste argumento?

    

Answer 1

O SMB pode ser mais lento que alguns outros protocolos de compartilhamento de arquivos, e pode ser mais rápido do que outros. Mas essa não é a parte importante.

Em vez de fazer essa pergunta / argumento, você pode encontrar uma maneira de seguir em frente e perguntar se o SMB é tão rápido (ou tão lento!) como é suposto ser. Por exemplo, você pode transferir um arquivo usando FTP entre o servidor e uma estação de trabalho que sofre com a lentidão e vê um salto acentuado no desempenho?

O fornecedor pode ser capaz de apontar para revisões do hardware, com o Windows instalado, que falam sobre o desempenho do servidor de arquivos.

Na minha experiência, o SMB é mais do que "rápido o suficiente" na minha rede. Estamos executando uma rede de 10 Gb entre os servidores e estamos muito satisfeitos com o desempenho do servidor de arquivos usando SMB e medimos o bom desempenho no mesmo hardware, dependendo de usarmos a NIC de 1 Gb ou 10 Gb. SMB não é um problema para nós.

Eu certamente estaria olhando outras coisas em sua rede - a infraestrutura está desatualizada, está configurada de maneira ideal (por exemplo, placas de rede do servidor configuradas corretamente para os drivers mais recentes, funcionando corretamente na melhor velocidade possível), coisas como DNS e tudo isso configurado corretamente, há muito tráfego "lixo" na rede causando lentidão, é o antivírus configurado de uma maneira excessivamente paranóica (já vi isso causar alguns atrasos chocantes ).

Há muita coisa que pode causar desempenho ruim do servidor de arquivos e muito pouco disso é a escolha do protocolo.

    

Answer 2

Embora existam protocolos mais rápidos do que o SMB, não é inerentemente lento.

É, no entanto, talvez um pouco mais suscetível a influências externas do que outros protocolos, sendo servidores saturados, segmentos saturados, etc.

Se eu fosse um homem de apostas, suspeitaria que sua rede poderia fazer um novo design ou algum investimento, já que muitas redes de escritórios regulares da empresa não foram atualizadas para levar em conta o enorme aumento do tráfego de Internet e intranet visto anos recentes. Também há uma chance razoável de que o (s) servidor (es) possam precisar de substituição ou retrabalho para obter o melhor deles.

De qualquer forma, eu não colocaria muita ênfase no SMB como o culpado direto, é mais do que provável que seja apenas o cara da queda para o kit de servidor / rede ruim / antigo.

    

Answer 3

Ele tem mais sobrecarga (para transferência) do que coisas como NFS ou FTP. Listagem de arquivos de diretórios grandes pode demorar um pouco - parte disso é devido a SMB, alguns devido a NTFS, alguns devido a coisas estúpidas que as várias versões do Explorer e software instalado, podem fazer do lado do cliente. Certos itens, como bancos de dados baseados em arquivos (Access, arquivos PST), não devem ser abertos em links (WAN) lentos, porque eles não lidam bem com a latência.

Dito isto, as operações que você descreve não devem demorar muito tempo. Talvez o servidor de arquivos (s?) Seja / não tenha potência suficiente. Talvez a empresa tenha algum software como parte da instalação padrão que atrasa as coisas. Talvez haja um scanner de vírus mal configurado. Talvez haja um vírus. Talvez exista um link WAN que você não conhece entre você e o servidor.

1. A listagem de arquivos é mais rápida se você fizer isso a partir de uma linha de comando em vez do Explorer?
2. Que tal copiar?
3. Efetue ping do servidor em questão a partir de sua área de trabalho - qual é a latência?
4. Faça um traceroute - quantos saltos existem entre você e o servidor?

Answer 4

Infelizmente, Nate, não podemos lidar diretamente com os PHBs. Sua primeira linha de defesa aqui é métricas reais, como em comparações entre transferência SMB e NFS, por exemplo.

Uma vez que você tenha números ou estatísticas reais para apoiar seus argumentos, você não precisará lidar com o elemento humano. As estatísticas dizem "aqui é onde está o problema e aqui está a prova". Esse é o seu argumento.

    

Answer 5

Você pode reduzi-lo? Uma transferência de servidor para servidor na mesma sub-rede tem melhores resultados? Que tal transferir de um cliente para outro ( \client\c$ & rightarrow; \client\d$ )?

Você pode encontrar algo tão simples quanto a incompatibilidade de duplex.

    

Answer 6

Eu sei que isso é antigo, mas um fator muito importante a ser levado em consideração é o disco de E / S. Se o desempenho de gravação em disco for incrivelmente lento devido ao RAID do software / placa-mãe, em oposição a uma placa RAID baseada em hardware com memória dedicada.

A carga de rede é um fator, mas a melhor coisa a fazer como um administrador de sistema é examinar o Monitor de Recursos e inspecionar de onde os gargalos podem estar originando - inspecionando a guia Visão Geral para mostrar CPU, Rede, E / S de Disco, Memória Desta perspectiva, você pode ver se há um processo culpado ou um conjunto de processos corroendo o Disk I / O, ou um vazamento de memória (SQLServer.exe - instância do SBSMonitoring), etc. Se houver um processo de rede usando Com muita largura de banda, verifique esse processo e inspecione quantos e quais hosts estão vinculados a esse processo. Poderia haver muitas tentativas de invasão no RDP em 3389. Eu já vi isso antes, já que o caso e nossa solução era remover o acesso RDP direto e deslocar os usuários remotos para a VPN.

Espero que isso ajude!