Eu precisava transferir um arquivo vdisk de 20 GB KVM , armazenando o sistema de arquivos raiz de uma VM do CentOS 6.5, de um servidor de laboratório para outro. O tamanho grande do arquivo e o fato de eu ter comprimido um arquivo vdisk para algumas centenas de megabytes me permitiram instintivamente a compactação com scp , mas fiquei surpreso ao ver uma velocidade de transferência bastante baixa. Então eu tentei bzip2 em combinação com ssh e cat e fiquei surpreso. Aqui está o resumo de métodos e taxa de transferência média.
scp -C vm1-root.img [email protected]:/mnt/vdisks/ , 11 MB / s. bzip2 -c vm1-root.img | ssh -l root 192.168.161.62 "bzip2 -d -c > /mnt/vdisks/vm1-root.img" , 5 MB / s. Este resultado ainda mais baixo levou à pesquisa na Internet. scp -c arcfour -C vm1-root.img [email protected]:/mnt/vdisks/ , 13 MB / s. Esse uso de -c arcfour foi sugerido em uma resposta no serverfault. Isso dificilmente ajudou. Por fim, desativei a compactação. scp vm1-root.img [email protected]:/mnt/vdisks/ , 23 MB / s. A compactação não deveria ter sido mais rápida?
EDIT: Eu não sei porque a pergunta foi downvoted. Eu pensei que há algo a ser aprendido aqui.
Depois de receber a dica de página ssh(1) man do @sven, tentei alguns métodos alternativos de transferência de arquivos que não envolvem compactação, ambos com melhores resultados.
cat vm1-root.img | ssh -l root 192.168.161.62 "cat > /mnt/vdisks/vm1-root.img" , 26 MB / s.
nc -l 5678 > /mnt/vdisks/vm1-root.img no receptor e nc 192.168.161.62 5678 < vm1-root.img no transmissor, 40 MB / s. A porta 5678 é arbitrária e estava disponível.
Usar nc acabou sendo o método de cópia mais rápido!
No passado, scp -C funcionou muito bem sempre que eu pensava que funcionaria. Por exemplo, ao transferir syslogs ( /var/log/messages* ) de alguns GBs em tamanho. Uma taxa de transferência não compactada de algumas centenas de KB / s aumentaria para 1-2 MB / s. Este exemplo se enquadra no caso de uma conexão lenta, como foi apontado na página man.
Eu tenho um caso em que, uma imagem vdisk recém-criada para uma partição de 20 GB tem um tamanho compactado de apenas 200 MB. Com uma taxa de transferência de cerca de 25 MB / s, poderíamos fazer a cópia em apenas 8 segundos, em vez de mais de 13 minutos! Claramente, scp sem compactação é ineficiente neste caso e scp -C é ainda pior.
Eu acho que a principal lição aprendida aqui é que scp -C deve ser pensado como sendo apenas uma conveniência. Se um arquivo puder ser significativamente compactado, é melhor compactá-lo primeiro na origem, transferir o formulário compactado e finalmente comprimir no destino. As ferramentas que fazem a compactação e a descompactação rapidamente (por exemplo, pbzip2 ) serão de maior ajuda.
Além disso, no topo da compactação, o nc obtém a melhor taxa, porque ele também não criptografa. E a compactação sem perdas depende da localização de seções redundantes dos dados, que, quando feitas no nível da rede, podem ter no máximo bytes [tamanho do buffer], quando feitas com o arquivo inteiro primeiro, são bytes [tamanho do arquivo] dentro do qual caçar e processar sentenças duplicadas de byte.
Também para mover imagens de disco, você deve usar uma ferramenta de reconhecimento de sistema de arquivos como ntfsclone / partclone, porque mesmo a compactação não pode superar apenas os blocos não alocados - sua taxa de transferência é infinita se você não precisar transferir nenhum dado. Também não se esqueça de destruir os arquivos de swap e hibernação em uma partição do Windows ou você está copiando o lixo que ele irá simplesmente jogar fora e recriar de qualquer maneira.
Tags ssh scp file-transfer