Por que o Samba SMB é mais lento que a transferência HTTP / NFS / FTP no NAS na minha LAN?

Question

Eu quero configurar um NAS que eu fiz mais recentemente com um Raspberry Pi 2 (ARM Cortex-A7 quad-core, 1GB de RAM, 32GB microSD) rodando Raspbian “Jessie”:

• Eu tenho um laptop - um HP Pavilion G6 - executando o Ubuntu 14.04 e usando 802.11b / g / n.
• Eu tenho um disco rígido externo USB 2.0 NTFS conectado a um Raspberry Pi 2, usando Samba e Apache, conectado à LAN do meu roteador sem fio a 100 Mbps.
• Quando tento transferir um arquivo usando o Samba SMB do Raspberry Pi 2, obtenho taxas de transferência inferiores a 1 milib / s.
• Quando eu transfiro um arquivo usando HTTP do Raspberry Pi 2, obtenho uma taxa de transferência típica de cerca de 3-4Mib / s [melhor, mas ainda bem lenta].
• Quando eu transfiro um arquivo usando FTP do Raspberry Pi 2, obtenho uma taxa de transferência típica de cerca de 2-4Mib / s [melhor, mas não tão boa quanto HTTP].

Por que a transferência de arquivos usando o Samba SMB transfere mais lento [3-4 vezes] do que o mesmo arquivo usando HTTP?

Não espero que 10-12Mib / s - embora próximo a ele seja bom - da minha rede local, pois há limitações em que a velocidade da rede seja de 100Mbs, conectando-se às limitações de USB 2.0 e Wi-Fi, mas pelo menos, deveria ser melhor que a Internet, que tem todos esses gargalos mais o que quer que esteja do lado de fora.

Poderia ser um problema de configuração do Samba?

Resultados do teste [taxas de transferência de arquivos de 1,5 Gb]:

• USB 3.0 : 70-80MiB / s

  Apenas USB.

  Disco rígido externo USB3.0 conectado à porta USB3.0 do laptop HP Pavilion G6.

  Arquivo transferido com o gerenciador de arquivos Dolphin.

  fonte: disco rígido USB3.0

  destino: laptop HP Pavilion G6

• USB 2.0 : 20-30MiB / s

  Apenas USB.

  Disco rígido externo USB3.0 conectado à porta USB 2.0 do Raspberry Pi.

  Arquivo testado usando pv raspberry~$ pv source > destination .

• Ethernet LAN: 8-9MiB / s

  Com fio.

  Disco rígido externo USB3.0 conectado à porta USB 2.0 do Raspberry Pi.

  Laptop HP Pavilion G6 conectado à rede via LAN Ethernet.

  Arquivo transferido usando samba smb:// .

  fonte: disco rígido USB3.0

  destino: laptop HP Pavilion G6

• Arquivo da Internet: 2-3 MiB / s

  Wi-Fi.

• Velocidade da LAN Wi-Fi HTTP: 3-4 MiB / s

  Wi-Fi.

  Disco rígido externo USB3.0 conectado à porta USB 2.0 do Raspberry Pi.

  Laptop HP Pavilion G6 conectado à rede via 802.11b / g / n Wi-Fi.

  Arquivo no apache webserver http:// .

  fonte: disco rígido USB3.0

  destino: laptop HP Pavilion G6

• Velocidade da LAN Wi-Fi do NFS: 3-4MiB / s

  Wi-Fi.

  Disco rígido externo USB3.0 conectado à porta USB 2.0 do Raspberry Pi.

  Laptop HP Pavilion G6 conectado à rede via 802.11b / g / n Wi-Fi.

  Arquivo transferido com o gerenciador de arquivos Dolphin.

  fonte: disco rígido USB3.0

  destino: laptop HP Pavilion G6

• Velocidade da LAN Wi-Fi FTP: 2-4 MiB / s

  Wi-Fi.

  Disco rígido externo USB3.0 conectado à porta USB 2.0 do Raspberry Pi.

  Laptop HP Pavilion G6 conectado à rede via 802.11b / g / n Wi-Fi.

  Arquivo no servidor vsftp ftp:// .

  fonte: disco rígido USB3.0

  destino: laptop HP Pavilion G6

• Velocidade da LAN Wi-Fi do SMB: < 900 KiB / s

  Wi-Fi.

  Disco rígido externo USB3.0 conectado à porta USB 2.0 do Raspberry Pi.

  Laptop HP Pavilion G6 conectado à rede via 802.11b / g / n Wi-Fi.

  Arquivo transferido usando samba smb:// .

  fonte: disco rígido USB3.0

  destino: laptop HP Pavilion G6

Como posso melhorar isso?

Aqui está a saída de iwconfig no meu laptop:

wlan0     IEEE 802.11bgn  ESSID:"Irk"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 34:31:C4:02:46:2D   
          Bit Rate=65 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=63/70  Signal level=-47 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:1369  Invalid misc:12350   Missed beacon:0

Veja aqui informações sobre a conexão de rede do meu Raspberry Pi por meio de dmesg | grep eth0 :

smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1

    

Answer 1

O dispositivo SoC usado no Pi não tem suporte embutido para ethernet, então a funcionalidade ethernet no Pi é fornecida por um chip ethernet USB, compartilhando o mesmo barramento USB que qualquer outro periférico USB que você possa ter conectado a ele ( incluindo quaisquer unidades flash USB). Esta é provavelmente a principal razão pela qual você vê um desempenho abismal.

Solução? Infelizmente não há nenhum, é uma limitação de hardware. Não tem nada a ver com a velocidade do seu disco rígido ou a configuração de rede que você tem, o barramento USB no Pi é levado ao seu limite com o disco e a ethernet rodando simultaneamente.

Você pode querer investir um pouco mais em sua configuração NAS e comprar um computador de placa única que realmente tenha incorporado uma rede ethernet. Existem várias plataformas com suporte a gigabit ethernet por aí.

    

Answer 2

TLDR: SMB & AFP tem criptografia mais volumosa e realmente faz mais do que apenas mostrar um índice dos arquivos. FTP e NFS estão lá apenas para lhe dar uma lista e fazer o trabalho. Seu RPI, como mencionado em outro comentário, é restrito por hardware ao barramento USB que move todos os dados de E / S. Mas 2-4Mbps é garbo, então verifique seu cliente e atualize todo o seu software, 10-18Mbps soa mais legítimo a menos que seu RPI ou comp estejam com defeito.

Não parece importar qual hardware é usado, o Samba é simplesmente lento. AFP (Apple File Protocol) não é melhor, eu tenho trabalhado com AFP e SMB desde 2008 usando Windows e Mac, é evidente que encontrei mais liberdade com o Linux, especialmente porque eles realmente melhoraram as capacidades de wifi do laptop e a economia está aumentando coisas como CHIP e RPIs pelos ouvidos. Mas o ponto é, SMB, AFP, NFS e FTP todos têm suas desvantagens. O SMB pode ser melhorado se você remover alguns dos recursos de segurança e o mesmo se aplica ao AFP. A razão pela qual você pode ver melhorias no FTP é a transferência muito simples que é, não há nenhum aperto de mão criptografado. O NFS bloqueia arquivos e similares ao FTP não é feito para "abrir" (copiar da máquina host para sua memória) e editar arquivos, ao contrário do SMB e AFP que são projetados para agir como se você estivesse navegando na máquina host.

    

Answer 3

Com base nos detalhes fornecidos na pergunta, veja alguns fatores que podem afetar a taxa de transferência local:

1. Os recursos no Raspberry Pi
2. A velocidade de leitura do disco rígido conectado via USB (a velocidade de leitura normalmente deve ser alta, mas não tenho certeza se a unidade está com defeito)
3. Os drivers USB no Raspberry Pi
4. O conector USB / caixa externa que conecta o disco rígido ao Raspberry Pi

Coisas que podem ser feitas para isolar o problema:

1. Conecte a "Unidade USB" diretamente à estação de trabalho que você está usando e verifique a velocidade de transferência
2. Use uma conexão com fio no Raspberry Pi (se ainda não configurada dessa forma)
3. Copie os arquivos do "USB Drive" para um armazenamento diferente no Raspberry Pi e verifique a velocidade de transferência
4. Copiar arquivos do Raspberry Pi (do eMMC não de um USB)
5. Crie um servidor web e / ou servidor FTP no Raspberry Pi e transfira os arquivos para a estação de trabalho através de http e ftp enquanto a estação de trabalho estiver em conexões sem fio e com fio (4 cenários diferentes - http com laptop em wired, http com laptop em wireless, ftp com laptop em com fio, ftp com laptop em wireless)
6. Conecte o "USB Drive" a uma estação de trabalho diferente na rede que não seja o Raspberry Pi e verifique a velocidade de transferência. Tente isso usando conexões com fio e sem fio.

Suposições:

• Não há outros dispositivos lendo a partir do "NAS" que foi configurado, o que também pode afetar a taxa de transferência.
• Você não está conectado à sua rede usando uma conexão com fio E sem fio. Se você estiver, há uma chance de que o tráfego para a Internet use uma interface e o tráfego local use outro que também possa afetar a velocidade de transferência.

Answer 4

Simplificando: NFS, FTP e HTTP são protocolos mais enxutos que as versões anteriores do SMB. Embora eu sempre defenda o uso do FTP para transferência de arquivos, pois onde ele pode ser mais enxuto que o SMB, ele não possui muitos dos recursos que tornam o armazenamento remoto seguro.

As versões posteriores do SMB o trazem mais em linha com o NFS, mas parece que você está executando o Samba 3.x, que é bem antigo (embora muito mais fácil de configurar).

Enquanto estamos discutindo o throughput, eu também aconselharia contra a execução do NTFS no Raspberry Pi, já que o driver Linuxes NTFS é o ntfs3g que é executado no FUSE. Para aqueles que não estão cientes do FUSE, é uma maneira de escrever drivers de sistema de arquivos que são executados no espaço do usuário, em vez do empacotador do FUSE, em vez de devs escrever módulos do kernel. Isso significa que você pode escrever drivers mais rápido, mais seguro e de maneiras mais interessantes (por exemplo, criei drivers FUSE que convertem o conteúdo de arquivos de texto em um sistema de arquivos virtual), mas isso tem um custo, já que você está constantemente trocando dados entre os kernel e espaço do usuário. Isso será menos perceptível em PCs - e ntfs3g é muito bem escrito também, o que ajuda - no entanto, em um dispositivo menor como o Raspberry Pi, sobrecarga extra de CPU e memória afetará seu desempenho em relação aos dados de fluxo de um arquivo nativo do Linux sistema como ext3 / 4 ou XFS.