Eu tenho dois computadores Debian Linux conectados via LAN de 1 Gbit. Eu posso medir isso com uma transferência de arquivo HTTP bruta com wget que fica em torno de 100MB / s em qualquer direção.
Quando agora uso scp , o máximo sem compactação que recebo é de cerca de 15MB / s . Ativar a compactação com o sinal -C me dá, dependendo do conteúdo, até 50MB / s .
Ainda assim, há uma largura de banda muito desperdiçada aqui, parece. Eu não me incomodei por um longo tempo até que eu realmente tive que pensar em algumas transferências de arquivos de log muito grandes e percebi o quão estranhamente lento o scp é. É natural para mim usar scp , mesmo no ambiente da empresa, porque toda a infraestrutura está configurada para isso.
O que limita muito o desempenho do scp? É CPU ligado por causa da criptografia? Quando eu uso htop parece que ele não usa CPUs multicore, apenas uma das quatro CPUs está no máximo.
Existe uma maneira de aumentar o rendimento? Eu tenho servidores HTTP e samba disponíveis, mas para mover arquivos entre máquinas Linux eu costumo usar SSH, é assim que eu cresci com isso. Mas isso agora me faz pensar sobre isso, parece que preciso considerar outras formas de transferência para grandes quantidades de dados.
O HTTP é usado apenas para aplicações específicas em PHP / Java / whatever e o samba é usado por algumas razões especiais que precisamos acessar em máquinas Windows.
Provavelmente é a criptografia. Você pode tentar scp com cifras diferentes, por exemplo:
scp -c arcfour src dest
Verifique a página de manual do ssh_config para obter as Cifras disponíveis. O RC4 (arcfour) é uma codificação rápida, mas provavelmente não tão segura quanto algumas alternativas.
Parte disso pode ter a ver com a implementação interna do OpenSSH. Dê uma olhada em HPN-SSH para obter uma explicação decente para um dos gargalos e correções para OpenSSH que pode resolvê-lo (se você estiver disposto a corrigir e reconstruir a partir da fonte).
Tags networking bandwidth scp