Por que estou vendo uma taxa de transferência tão baixa de SMB?


10

Ok, há um pouco mais na história do que o título implica.

Antecedentes e ambiente : estou copiando vários TB de um servidor Ubuntu mais antigo para um servidor Windows 2012 mais recente por SMB. (Tecnicamente, é um hardware comum, mas são servidores por aqui.) Todo mundo está em uma LAN de gigabit, e a antiga caixa do Ubuntu tem uma interface ligada. Acredito que o servidor Ubuntu tenha duas placas Ethernet Rosewill PCI-e 1x e o servidor Windows tenha uma placa Ethernet Intel razoavelmente agradável.

O computador de destino (o servidor Windows) está executando um pool de armazenamento com paridade em 4x unidades de 2 TB. Está executando o novo ReFS da Microsoft. O computador de origem (o servidor Ubuntu) está executando um espelho RAID de software. Está executando o bom e velho EXT4.

Os dois servidores estão executando através de um único switch de gigabit. Eu experimentei quebrar a ligação no computador de origem (Ubuntu) sem nenhuma melhoria.

Problema : Não tenho problemas ao transferir a velocidades razoáveis ​​de outros computadores para o servidor Windows. Outros computadores podem suportar 50-80MB / s sem muita dificuldade, mas a transferência desse servidor Ubuntu atinge o limite máximo de 20MB / s. 4 + TB a 20 MB / s leva muito tempo (algo como 2,3 dias), e eu estou pensando no que posso fazer para descobrir onde está o gargalo.

Sintomas : a CPU nos dois computadores é bastante mínima e, certamente, não é proibitivamente ocupada. Os discos rígidos nos dois computadores estão ativos, mas não inundados, e o IOwait da CPU é quase 0% no servidor Ubuntu.

Fiz um rastreamento do Wireshark por 35 segundos (presumivelmente tempo suficiente para garantir que todos os ACKs fossem para novos pacotes) e notei que havia algumas coisas que eu não esperava. (1) Não havia nenhuma soma de verificação para os ACKs (e ALGUNS pacotes SMB) do Windows para o Ubuntu. No entanto, o Wireshark alega que isso pode ocorrer devido a "descarga de soma de verificação de IP". Ok, eu tenho um cartão muito bonito lá. Suponho que seja possível que a placa de rede faça cálculos de soma de verificação. Bem. Seguindo em frente ... (2) "O TCP não reconheceu o segmento invisível." Este aqui eu tenho um problema. O número ACK está dentro de um intervalo aceitável do que eu sei, e muitas vezes existem enormes blocos dessas mensagens. Talvez o Wireshark seja lento demais?

Resumo : A velocidade de transferência é uma porcaria (20MB / s em Ethernet de gigabit) e não sei por quê. O Wireshark afirma que o Windows está aceitando coisas que nunca foram enviadas pelo Ubuntu.

Palpites : Meu palpite inicial é que os cartões mais baratos da Rosewill estão sendo inundados. Meu segundo palpite é que as coisas do tipo RAID de software, de um lado ou de outro, estão ficando inundadas de coisas para fazer.


2
Quais velocidades você obtém a cópia do servidor Ubuntu para um dos desktops (não o Server 2012)? Talvez WinXP ou Win7? Eu tive grandes problemas com a assinatura e a criptografia de pacotes no SMB com o Server 2008 e versões posteriores.
Dom

Atualização: acabei tendo que reiniciar (graças a um pânico no kernel). Infelizmente, o sistema agora tem um pânico no kernel em cada inicialização. Peguei minha cópia confiável do Knoppix e montei as unidades, e agora tudo está bem. Agora estou copiando pelo SSH e ainda não sei onde está o gargalo. sshdestá consumindo 60% de um processador no lado do Knoppix. De qualquer forma, minha transferência está quase concluída. @ Dom: Agora que você mencionou, não me lembro de colocar todos esses dados lá muito mais rapidamente do que 30 MBps em primeiro lugar.
21413 Andy

2
@LorenzoVonMatterhorn, evite usar encurtadores de URL.
Cristian Ciupitu 20/10/2013

Tem certeza de que não há problema com seus discos?
MariusMatutiae

2
O Windows implementou uma versão muito rápida do protocolo SMB (SMB 2) nos últimos 4-5 anos, que é muito menos faladora e mais eficiente na conexão. Eu não sei de imediato quando essas mudanças foram lançadas no Samba, mas parece que o Ubuntu mais antigo tem um Samba mais antigo e talvez o Knoppix tenha uma versão mais recente.
uSlackr

Respostas:


1

Seu hiato de desempenho corresponde a uma experiência comum quando o Samba (não tenho certeza se esse ainda é o padrão; foi por um longo tempo) está configurado com o tamanho padrão do buffer de soquete de leitura e gravação de 1024 bytes.

Eu costumava ver isso frequentemente em máquinas Linux e Mac. Espero que ainda não seja esse o caso.

Há um argumento de opção de soquete no arquivo de configuração do samba, no qual você pode definir o tamanho do buffer de leitura e gravação do soquete. Sugira que você defina os dois como 8192 bytes (8 KiB). 4 ou 8 KB geralmente são semelhantes, mas eu não testei isso em um link de gigabit.

Além disso, não espere que uma única conexão TCP se beneficie de um link vinculado; o tráfego quase sempre passará por um dos links; caso contrário, você terá muitos pacotes com problemas para lidar; portanto, espere apenas um benefício de balanceamento de carga ao atender vários clientes. Mesmo assim, você deve procurar os diferentes modos de ligação e saber que, para pelo menos a ligação "modo 4" (IEEE 802.3ad), existem basicamente dois modos de transmissão hash, que determinam em qual interface escrava enviar. Há hash da camada 2 (padrão) e hash da camada 3. Se enviar a maior parte dos seus dados via gateway, o hash da camada 2 não será distribuído corretamente, pois o endereço MAC do gateway será o mesmo. Considere usar a camada 3.


0

Certa vez, eu tinha duas placas Ethernet em um computador Ubuntu e, por algum motivo, não funcionou corretamente - ambas disputavam os mesmos pacotes que pareciam, então às vezes eu recebia uma resposta às vezes não, dependendo se a outra placa de rede pegava o embalado. Isso foi estranho. Devo ter confundido de alguma forma, mas pensei que teria funcionado. Os cartões tinham endereços IP únicos, é claro.

De qualquer forma, seria simples tentar com apenas uma placa Ethernet na máquina conectada à rede apenas para descartar isso.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.