为什么压缩比没有压缩慢?

我需要将一个20 GB KVM虚拟磁盘文件从一个实验室服务器传输到另一个实验室服务器,将一个CentOS 6.5虚拟机的根文件系统存储起来。 大的文件大小和我曾经压缩这样的虚拟磁盘文件到几百兆字节的事实使我本能地使用scp进行压缩,但是我惊讶地发现传输速度相当低。 然后我尝试了bzip2sshcat组合,并被吓了一跳。 以下是方法和平均吞吐量的总结。

  • 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" bzip2 -c vm1-root.img | ssh -l root 192.168.161.62 "bzip2 -d -c > /mnt/vdisks/vm1-root.img" / s。 这更低的结果提示在网上search。
  • scp -c arcfour -C vm1-root.img [email protected]:/mnt/vdisks/ ,13 MB / s。 在serverfault上的一个答案中提到了-c arcfour 。 它几乎没有帮助。 最后,我禁用了压缩。
  • scp vm1-root.img [email protected]:/mnt/vdisks/ ,23 MB / s。

不应该压缩更快?

编辑:我不知道为什么这个问题已经downvoted。 我认为这里有一些东西需要学习。

在从@sven接收到ssh(1)手册页提示后,我尝试了一些不涉及压缩的文件传输替代方法,两者都有更好的结果。

  • cat vm1-root.img | ssh -l root 192.168.161.62 "cat > /mnt/vdisks/vm1-root.img" cat vm1-root.img | ssh -l root 192.168.161.62 "cat > /mnt/vdisks/vm1-root.img" MB / s。

  • nc -l 5678 > /mnt/vdisks/vm1-root.img在接收器上, nc 192.168.161.62 5678 < vm1-root.img在发送器上,40 MB / s。 端口5678是可用的任意一个。

使用nc竟然是最快的复制方法!

在过去,每当我想到的时候, scp -C都运行得很好。 例如,在传输大小为几GB的系统日志( /var/log/messages* )时。 几百KB / s的未压缩传输速率将增加到1-2 MB / s。 这个例子确实在连接速度慢的情况下,正如手册页中指出的那样。

我有一个情况,一个新创build的20 GB分区的虚拟磁盘映像的压缩大小只有200 MB。 传输速率约为25 MB / s,我们可以在8秒内完成复制,而不是13分钟以上! 显然,没有压缩的scp在这种情况下是低效的,并且scp -C更糟糕。

我想,这里学到的主要教训是,应该认为scp -C只是一种方便。 如果一个文件可以被显着压缩,那么最好先在源文件上压缩它,传输压缩的表格,最后在目的地上进行压缩。 快速进行压缩和解压缩的工具(例如pbzip2 )将有更大的帮助。

引用man ssh (这是scp使用的基础):

在现代线路和其他慢速连接上压缩是可取的,但只会减慢快速networking的速度。

问题是,压缩数据需要更多的时间,然后通过networking发送。

另外,除了压缩之外,nc也是最好的,因为它也不encryption。 而无损压缩依赖于find数据的冗余部分,当在networking级完成时,您可以查看最大[buffer-size]字节,其中当首先完成整个文件时,它是[file-size]字节在其中寻找和紧缩重复的字节句子。

另外,对于移动磁盘映像,您应该使用像ntfsclone / partclone这样的文件系统感知工具,因为即使压缩也无法简单地跳过未分配的块 – 如果您不必传输任何数据,则传输速率是无限的。 另外不要忘记在Windows分区上销毁交换文件和hibernate文件,否则就是在复制垃圾文件,它将会丢弃并重新创build。