Perché scp con compressione è più lento che senza?

11

Avevo bisogno di trasferire un file vdisk KVM da 20 GB , memorizzando il filesystem di root di una VM CentOS 6.5, da un server di laboratorio a un altro. Le grandi dimensioni del file e il fatto che una volta avevo compresso un tale file vdisk a poche centinaia di mega byte mi hanno istintivamente abilitato la compressione con, scpma sono stato sorpreso di vedere una velocità di trasferimento piuttosto bassa. Poi ho provato bzip2in combinazione con sshed cate sono rimasto sorpreso. Ecco il riepilogo dei metodi e della produttività media.

scp -C vm1-root.img root@192.168.161.62:/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. Questo risultato ancora più basso ha richiesto la ricerca in rete.
scp -c arcfour -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 13 MB / s. Questo uso di -c arcfouras è stato suggerito in una risposta su serverfault. Difficilmente aiutato. Infine, ho disabilitato la compressione.
scp vm1-root.img root@192.168.161.62:/mnt/vdisks/, 23 MB / s.

La compressione non avrebbe dovuto essere più veloce?

EDIT: non so perché la domanda sia stata sottoposta a downgrade. Ho pensato che ci fosse qualcosa da imparare qui.

Dopo aver ricevuto il ssh(1)suggerimento sulla pagina man da @sven, ho provato un paio di metodi alternativi di trasferimento dei file che non prevedevano la compressione, entrambi con risultati migliori.

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.imgsul ricevitore e nc 192.168.161.62 5678 < vm1-root.imgsul trasmettitore, 40 MB / s. La porta 5678è arbitraria disponibile.

L'utilizzo ncsi è rivelato essere il metodo di copia più veloce!

In passato, scp -Cha funzionato molto bene ogni volta che pensavo che avrebbe funzionato. Ad esempio, quando si trasferiscono syslogs ( /var/log/messages*) di dimensioni di pochi GB. Una velocità di trasferimento non compressa di poche centinaia di KB / s aumenterebbe a 1-2 MB / s. Questo esempio cade nel caso di una connessione lenta, come è stato sottolineato nella pagina man.

Ho un caso in cui, un'immagine vdisk appena creata per una partizione da 20 GB ha una dimensione compressa di soli 200 MB. Con una velocità di trasferimento di circa 25 MB / s, potremmo eseguire la copia in soli 8 secondi anziché in 13 minuti! Chiaramente, scpsenza compressione è inefficiente in questo caso ed scp -Cè anche peggio.

Immagino che la lezione principale appresa qui sia che scp -Cdovrebbe essere considerata solo una comodità. Se un file può essere compresso in modo significativo, è meglio comprimerlo prima sull'origine, trasferire il modulo compresso e infine decomprimere sulla destinazione. Gli strumenti che eseguono rapidamente la compressione e la decompressione (ad esempio pbzip2 ) saranno di grande aiuto.

ssh scp file-transfer

— pdp
fonte

9

Citando man ssh(che è la base utilizzata da scp):

La compressione è desiderabile su linee modem e altre connessioni lente, ma rallenterà le cose solo su reti veloci.

Il problema è che la compressione dei dati richiede più tempo rispetto all'invio sulla rete.

— Sven
fonte

Stava specificatamente chiedendo perché la velocità di trasferimento fosse inferiore, ma sospetto che ssh la calcoli effettivamente dividendo la dimensione dei dati per il tempo totale dell'intera operazione e non separando la parte in cui comprime i dati e la parte in cui copia i dati sul Rete.

— Ernie

@Ernie: se riesci a trasmettere dati con una velocità di 20 MB / s e il sistema può inviarli solo con 15 MB / s perché la compressione è così lenta, verrà trasmessa con solo 15 MB / s. Questo è tutto quello che c'è da fare.

— Sven

@Ernie: la velocità di trasferimento stampata da scpinclude il tempo impiegato per la compressione / decompressione. I valori riportati sembrerebbero sorprendenti se non fosse così.

— pdp,

0

Inoltre, oltre alla compressione, nc ottiene la tariffa migliore perché non crittografa neanche. E la compressione senza perdita di dati si basa sulla ricerca di sezioni ridondanti dei dati, che una volta eseguita a livello di rete è possibile esaminare un massimo di [dimensioni buffer] byte, mentre quando viene eseguita per prima con l'intero file, si tratta di [dimensioni file] byte all'interno del quale cercare e sgranocchiare frasi di byte duplicate.

Anche per spostare le immagini del disco dovresti usare uno strumento compatibile con il filesystem come ntfsclone / partclone perché anche la compressione non può battere semplicemente saltando i blocchi non allocati - la tua velocità di trasferimento è infinita se non devi trasferire alcun dato. Inoltre, non dimenticare di distruggere i file di scambio e di ibernazione su una partizione di Windows o stai copiando la spazzatura che semplicemente getterà via e ricreare comunque.

— Tony Butler
fonte