velocidade de rede direcionada pela LAN

0

Eu tenho um sistema Solaris 11 que possui várias exportações NFS que são acessadas por outros sistemas da minha LAN. Eu uso um sistema Linux como cliente para testes.

Eu escrevi um script rápido para testar a velocidade de leitura e a média é de cerca de 110Mbps (ou 13MB / s) em uma LAN Gigabit. E eu acho que poderia ficar muito mais rápido. SSH (scp) só me dá 3,8MB / s, mas isso é com criptografia.

link

qual poderia ser o gargalo desses números?

    
por shigazaru 27.12.2012 / 04:34

4 respostas

1

O NFS não pode realmente maximizar o throughput, porque o cliente continua enviando por favor me envie este tanto dados para o servidor ( isso sendo limitado a alguns kilobytes) e aguarda a resposta completa antes de pedir mais, o que significa dead vezes, quando todas as filas estão vazias. Todo o FS na rede (CIFS, SSHFS) tem o mesmo tipo de problema (e IIRC scp também, ou talvez seja apenas sftp , não me lembro)

Além da sobrecarga de criptografia, ssh também tem mais algumas limitações de desempenho (consulte aqui para obter detalhes ).

HTTP, a menos que você use um cliente que executa solicitações em partes, deve ser TCP direto, então não deve ter esse tipo de limitação. O TCP deve usar seu algoritmo de controle de congestionamento para maximizar o rendimento, evitando o congestionamento. Enquanto os primeiros kilobytes podem ser transferidos lentamente, você deve ser capaz de maximizar sua largura de banda em alguns 10 segundos se as duas máquinas estiverem conectadas através do mesmo switch. É possível que haja alguma qualidade de rede ruim (como a perda de pacotes ímpares).

Coisas que você pode querer tentar:

  • Transfira o conteúdo de /dev/zero por uma conexão TCP simples (usando socat ou nc , por exemplo), para excluir o gargalo da garrafa que é o acesso à FS.
  • Verifique as estatísticas da interface de rede em busca de erros de transmissão e as estatísticas da pilha TCP ( netstat -s )
  • Teste com iperf (TCP e UDP).
por 28.12.2012 / 00:06
1

Eu tive uma situação semelhante no passado, e meu jeito de resolver foi forçar o Solaris e o Linux a montar o NFS v3 ao invés da v4.

Do lado do Solaris, você pode editar o / etc / default / nfs e definir as variáveis para o lado do servidor para o servidor e aceitar apenas o lado do NFS v3.

Não consegue lembrar os nomes das variáveis, mas é auto-explicativo.

O teste que você fez foi copiar um único arquivo grande ou vários arquivos? Se forem vários arquivos eu não ficaria surpreso, mas se for um arquivo único do que sim.

Além disso, que tipo de armazenamento subjacente você tem? disco único? configuração de invasão? isso também afeta seu desempenho.

    
por 27.12.2012 / 08:54
0

Com que rapidez o sistema de arquivos subjacente pode fornecer dados? O próprio NFS pode mover dados mais rapidamente do que você está vendo, o que sugere que existem outros gargalos. Você pode se convencer disso usando o iperf para confirmar que a rede pode transmitir uma maior largura de banda.

Eu faria logon no sistema solaris e copiaria um arquivo do sistema de arquivos que você está exportando para / dev / null para ver a velocidade com que você pode fazer o stream. Note que você precisará fazer algum esforço para não fazer este teste de leitura de um arquivo que já esteja no cache do sistema de arquivos. Com outros sistemas de arquivos, você pode desmontar / montar para invalidar o cache, mas isso por si só pode ser insuficiente para o ZFS.

    
por 09.01.2013 / 14:17
0

Você precisa estar ciente dos recursos de cada parte de sua pilha. Que tipo de discos compõem o sistema de arquivos para o compartilhamento NFS? SAS? SATA SSD? Que tipo e tamanho e velocidade de rpm de cada um? latência rotacional? É uma unidade de 4k? O ZFS é otimizado para unidades de 512 bytes e há problemas conhecidos com o desempenho usando novos discos de "formato avançado".

Qual é o tamanho da sua carga de trabalho de E / S? Isso também afeta a rapidez com que seu armazenamento será exibido.

De uma perspectiva puramente de armazenamento, essas perguntas afetarão a velocidade com que os dados podem ser gravados e lidos nos discos de back-end. Por exemplo, digamos que seu compartilhamento NFS esteja vindo de um sistema de arquivos em um disco SATA de 7200 RPM de 1TB e que seu tamanho de carga de trabalho seja de 64 KB e seja na maior parte aleatório.

Random Workload, 64 KB IO size
--------------------------------------------------------------------------------
Average Read Seek Time:        8.4 ms
Average Write Seek Time:       8.9 ms
Rotational latency:           .120 ms
Average Latency:             4.166 ms
Average Read Service Time:  12.566 ms
Average Write Service Time: 13.066 ms
--------------------------------------------------------------------------------
Best Case Read IOPs:           79.000
Best Case Write IOPs:          76.000
--------------------------------------------------------------------------------
Best Case Read Throughput:  4.937 MB/s
Best Case Write Throughput: 4.750 MB/s
--------------------------------------------------------------------------------
Real World Read IOPs:         55.300
Real World Write IOPs:        53.200
--------------------------------------------------------------------------------
Real World Read Throughput:  3.325 MB/s
Real World Write Throughput: 3.325 MB/s
--------------------------------------------------------------------------------

Isso lhe dará uma idéia do desempenho do mundo real que você pode esperar obter de um único disco em um determinado tamanho de carga de trabalho.

Você pode aumentar esse desempenho criando um cache de gravação ou montando o sistema de arquivos NFS de forma assíncrona, para que as confirmações de gravação não sejam necessárias antes do início da próxima E / S (não que eu recomende isso, pois coloca seus dados em risco ).

Depois de entender o desempenho do seu armazenamento de back-end, você pode começar a observar a sobrecarga adicional criada pelo NFS (é v3? v4? tcp? udp?) ou SSH (qual algoritmo de criptografia você está usando? use um algoritmo mais leve como arcfour para melhorar o desempenho) ou a própria rede. Você tem um NIC barato de 1 GbE? ou um NIC de qualidade de servidor de ponta? você está compartilhando esse nic entre vários serviços? alguma coisa está gerando tráfego na sua rede? Como sobre o congestionamento da rede, colisões ou altas taxas de retransmissão?

Tudo isso é somado para reduzir ainda mais o aparente desempenho do seu armazenamento de back-end, o que significa que todos são adicionados para fazer as coisas parecerem muito lentas no lado do cliente.

Agora, os números acima são uma espécie de pior cenário, certo? Carga de trabalho síncrona aleatória de 100%. Se você tiver uma carga de trabalho sequencial ou aumentar o tamanho da carga de trabalho de E / S, poderá aumentar drasticamente o desempenho. Por exemplo, se você conseguir aumentar seu tamanho de E / S para 128k, duplicará seu desempenho e, dependendo do seu cliente NFS, poderá definir rsize e wsize para várias configurações para testar o desempenho. Afinal, há um ponto de retornos decrescentes.

E se você tiver vários discos, no espelho ou no RAID, terá que ajustar seus números para isso.

O Real World Disk Performance quase nunca é impresso no lado da caixa em que o disco entrou.

    
por 11.01.2013 / 17:07