Ronaldo Reis-Jr. wrote:
Em Sábado 20 Maio 2006 14:22, Marcos Vinicius Lazarini escreveu:
Ronaldo Reis-Jr. wrote:
ao invez de usar fish, tente sftp
Em ultimo caso vc pode deixar a compressão ligada por default no servidor
Agora comparar o sftp c/ o rsync é crueldade... :-)
--
Marcos
Marcos,
Blz
Testei com o sftp e ele é mais lento que o fish. Não entendo porque o rsync
seria tão mais rápido, não estou usando via servidor rsync, mas sim via ssh,
então acho que quem define a velocidade é o ssh, ou não?
Mas vou tentar exemplificar melhor o ocorrido.
Tenho dois computadores chamados fasterix e mobilix conectados por um cabo de
rede invertido.
Algumas especificações que acho que podem ter haver com a questão:
fasterix:
Intel(R) Pentium(R) 4 CPU 1.70GHz
cache size : 256 KB
Mem. RAM: 1 GB
Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] (rev 86)
mobilix:
Intel(R) Pentium(R) M processor 1.60GHz
cache size: 2048 KB
Mem. RAM: 512 MB
Ethernet controller: Broadcom Corporation NetXtreme BCM5705M Gigabit Ethernet
O dois com Debian/Testing sempre atualizado.
Todos os procedimentos de transferência foram realizados com o protocolo fish
no kde.
As velocidades foram:
mobilix <- fasterix [~10mb/s]
mobilix -> fasterix [~1.2mb/s]
fasterix <- mobilix [~3.7mb/s]
fasterix -> mobilix [~1.2mb/s]
As configurações do servidor ssh são iguais e não modificadas, ou seja, são as
mesmas instaladas por default.
A questões que ficam são:
Por a diferença tão grande entre as velocidades de download (<-) e de upload
(->)?
Porque a diferença tão grande entre as velocidades de download (<-) dos dois
computadores (10mb/s X 3.7mb/s)
Porque esta diferença de download não se repete no upload?
O que fazer para melhorar a performance? Ativar a compactação de dados no
servidor ssh? Como se faz? Ou ativar nos clientes?
Só para ver se ajuda, o mesmo teste usando o scp via terminal a partir do
mobilix
Velocidades de uploads:
[EMAIL PROTECTED] ~]$ scp Teste.mpg [EMAIL PROTECTED]:./
Teste.mpg 100% 72MB 11.9MB/s 00:06
[EMAIL PROTECTED] ~]$ scp -C Teste.mpg [EMAIL PROTECTED]:./
Teste.mpg 100% 72MB 5.5MB/s 00:13
[EMAIL PROTECTED] ~]$ scp Teste.mpg [EMAIL PROTECTED]:./
Teste.mpg 100% 72MB 11.9MB/s 00:06
[EMAIL PROTECTED] ~]$ scp -C Teste.mpg [EMAIL PROTECTED]:./
Teste.mpg 100% 72MB 5.1MB/s 00:14
Velocidades de downloads:
[EMAIL PROTECTED] ~]$ scp [EMAIL PROTECTED]:./Teste.mpg ./
Teste.mpg 100% 72MB 11.9MB/s 00:06
[EMAIL PROTECTED] ~]$ scp -C [EMAIL PROTECTED]:./Teste.mpg ./
Teste.mpg 100% 72MB 3.1MB/s 00:23
[EMAIL PROTECTED] ~]$ scp [EMAIL PROTECTED]:./Teste.mpg ./
Teste.mpg 100% 72MB 10.2MB/s 00:07
[EMAIL PROTECTED] ~]$ scp -C [EMAIL PROTECTED]:./Teste.mpg ./
Teste.mpg 100% 72MB 3.3MB/s 00:22
Aí o mais estranho, pois o -C é para justamente para habilitar a compressão
dos dados, desta forma eu esperaria que a transmissão de dados com -C fosse
mais rápida, porém não foi isto que ocorreu.
Ronaldo, vamos tentar esclarecer umas coisas.
o fish:// funciona atraves do ssh + scripts em perl na máquina remota (entre
num diretório como /usr/share ou /usr/share/doc e veja com o top uns
processos perl aparecendo e sumindo). Já o sftp:// utiliza direto o
protocolo sftp (existe um comando sftp p/ os desavisados, muito semelhante
ao ftp). A diferença de desempenho tbm está relacionada com a diferença de
implementação.
Outra coisa, achei o arquivo que vc testou pequeno, pois transferiu em até
menos de 10 segundos. Talvez um de + de 1 GB (p/ nao caber nada no cache) ou
um de 300 MB (p/ caber no cache dos dois).
Os micros são +- rápidos e vc tá trabalhando proximo do limite de saturação
da rede 100 Mbps (teóricos 12.5 MB/s). Mas pelos seus resultados, o uso de
CPU deve estar bem alto - pois quando vc liga a compressão, a CPU não dá
mais conta de comprimir nessa taxa e acaba segunrado a transmissão. Leia na
manpage do ssh:
[...]
The compression algorithm is the same used by gzip(1), and the ``level''
can be controlled by the CompressionLevel option for protocol version 1.
Compression is desirable on modem lines and other slow connections, but will
only slow down things on fast networks.
[...]
deixe rolando uma transmissão e monitore a CPU com o top (ou com o htop)
Outra comentário é que no exemplo vc está tentando comprimir um .mpg, que
não deve comprimir quase nada... então isso literalmente é esforço jogado
fora. Se seus dados forem isso, mais um motivo p/ não usar compressão.
Voltando...
O rsync usa muito I/O de disco e um bom tanto de CPU - se o disco de uma
máquina for lento, isso pode atrasar todo o processo. Isso acontece
justamente p/ se evitar transferir muitos dados que já foram transferidos
atualmente... Muito bem dito pelo admin do kernel.org, o rsync "trades
bandwidth for CPU horsepower" [1]
Já o unison (nunca usei) tem um trabalho extra que é justamente saber quem
tem que mandar o que pra onde, e me parece q ele mandem uma série de
informações num .unison da vida - se algum disco seu tiver uma velocidade de
I/O ruim, provavelmente vai afetar bastante o desempenho...
Quanto as grandes diferenças de velocidade de transmissão, não sei pq isso
acontece, mas já tive esses problemas - e nao sei como resolver. No caso da
linha de comando, é fácil resolver... basta logar na máquina certa. O fato é
que o ssh é um protocolo pesado, que usa bastante CPU - e nao sei se é
simetrico em termos de CPU (ambos os hosts, gastam o mesmo tanto?)
[1] http://kerneltrap.org/node/5070
--
Marcos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
