Ao gravar em disco (SATA), notei que o tar parece ter um grande impacto no desempenho. Estou tentando copiar um arquivo .dmg relativamente grande (556 MB) do meu cliente (OSX) em toda a minha rede local como parte de um backup para o meu servidor (debian). Tentando o método típico, os resultados foram muito ruins em termos de velocidade de transferência do cliente e E / S no servidor
Para monitoramento de E / S, os dois: iostat -Ndx 1 e iotop -oa foram usados no servidor
scp: ~18 minutes de rendimento no cliente ~500KB/s-540KB/s I / O no servidor ~800kB/s-1100kB/s
( time scp <my_file> user@host:/path/to/dir/ )
sftp: ~ 50% mais rápido ~9 minutes de rendimento no cliente ~1MB/s E / S no servidor ~1500kB/s-2000kB/s , mas não pode ser roteirizado, pois usei o gui ciberduck
Mais pesquisas renderam / a> e então eu tentei o seguinte:
No cliente:
( tar -cf - <my_file> | pv -s $(du -sb <my_file> | awk '{print $1}') | nc -l 8888 )
No servidor:
( nc <source_ip> 8888 | tar xf - )
OBSERVAÇÃO: deixei de usar pigz de uso, já que ele parecia causar uma transferência da queda do cliente para 0 Kb/s com frequência durante a transmissão.
Isso gerou os piores resultados de cerca de ~33 minutes com a taxa de transferência no cliente sendo ~300-400KB/s e E / S no servidor ~800-1200KB/s , que nos últimos 5 minutos caiu para ~200KB/s e E / S de ~800KB/s respectivamente.
Para garantir que não foi a rede, modifiquei o servidor para ( nc <source_ip> 8888 > /dev/null ) e o tempo de transferência caiu para ~2minutes com taxa de transferência do cliente em ~6-7MB/s .
Por meio de mais pesquisas na página man, decidi modificar o tamanho do bloco ( -b, --blocking-factor ) para valores mais altos, ou seja, 128, 512, 1024, etc ..., o que resultou em um desempenho de gravação muito melhor, sendo -b1024 comparável ao teste de redirecionamento para /dev/null . A página man parece um pouco datada, mas apenas se refere à alteração dessa opção em relação à gravação em fita e não faz menção à mídia moderna. É possível que existam implicações negativas para a integridade dos dados para isso? Por esta modificação, e de acordo com a página man, eu assumo que o tar está tentando gravar os dados em blocos de 512 bytes, modificando-os para 512 * 1024, que são blocos de 512KB, não sei se haveria um problema para o sistema operacional para escrever isso.
EDITADO:
originalmente postado longe de computadores, então atualizei os comandos reais usados, forneceu tempos mais precisos e corrigiu erros de digitação. Também tentei sugerir criptografia scp conforme sugerido abaixo e incluiu resultados
scp: ~17.5 minutes taxa de transferência no cliente ~500KB/s-540KB/s E / S no servidor ~1100kB/s-1500kB/s
( scp -C <my_file> user@host:/path/to/dir/ )
com tamanho de bloco modificado: ~42 seconds de rendimento no cliente e E / S no servidor ~15MB/s
cliente: ( tar --disable-copyfile -cf - <my_file> | pv -s $(du <my_file> | awk '{size = $1 * 512} END {print size}') | nc -l 8888 )
servidor: ( nc 10.0.1.28 8888 | tar -b1024 -xf - )