Love Sun

Linux大文件传输

我们经常需要在机器之间传输文件。比如备份,复制数据等等。这个是很常见,也是很简单的。用scp或者rsync就能很好的完成任务。但是如果文件很大,需要占用一些传输时间的时候,怎样又快又好地完成任务就很重要了。在我的测试用例中,一个最佳的方案比最差的方案,性能提高了10倍。

复制文件

如果我们是复制一个未压缩的文件。这里走如下步骤:
  1. 压缩数据
  2. 发送到另外一台机器上
  3. 数据解压缩
  4. 校验正确性
这样做会很有效率,数据压缩后可以更有效的利用带宽

使用ZIP+SCP

我们可以通过ZIP+SCP的组合实现这个功能。
data文件的大小是1.1GB,经过Zip压缩后是183MB,执行上面的命令需要45.6s。平均吞吐量为24.7MB/s
我们会发现Scp也有压缩功能,所以上面的语句可以写成
可是我执行上面一条命令的时候,发现还是需要45s。平均吞吐量还为24MB/s。没有丝毫的提升,可见瓶颈不在网络上。
那瓶颈在哪里呢?

性能分析

我们先定义几个变量

  • 压缩工具的压缩比是 CompressRadio
  • 压缩工具的压缩吞吐是CompressSpeed MB/s
  • 网络传输的吞吐是 NetSpeed MB/s

由于使用了管道,管道的性能取决于管道中最慢的部分的性能,所以整体的性能是:

speed=min(NetSpeed/CompressRadio,CompressSpeed)

当压缩吞吐较网络传输慢的时候,压缩是瓶颈;但网络较慢的时候,网络传输/吞吐 是瓶颈。

根据现有的测试数据(纯文本),可以得到表格:

压缩比 吞吐量 千兆网卡(100MB/s)吞吐量 千兆网卡吞吐量,基于ssh(62MB/s) 百兆网卡(10MB/s)吞吐量
ZLIB 35.80% 9.6 9.6 9.6 9.6
LZO 54.40% 101.7 101.7 101.7 18.38235294
LIBLZF 54.60% 134.3 134.3 113.5531136 18.31501832
QUICKLZ 54.90% 183.4 182.1493625 112.9326047 18.21493625
FASTLZ 56.20% 134.4 134.4 110.3202847 17.79359431
SNAPPY 59.80% 189 167.2240803 103.6789298 16.72240803
NONE 100% 300 100 62 10

可以看出来。在千兆网卡下,使用QuickLZ作为压缩算法,可以达到最高的性能。如果使用SSH作为数据传输通道,则远远没有达到网卡可以达到的最佳性能。在百兆网卡的情况下,各个算法相近。对比下来QuickLZ是有优势的。

对于不同的数据和不同的机器,可以得出不同的最佳压缩算法。但有一点是肯定的,尽量把瓶颈压在网络上。对于较慢的网络环境,高压缩比的算法会比较有优势;相反对于较快的网络环境,低压缩比的算法会更好。

结论

根据上面的分析结果,我们不能是用SSH作为网络传输通道,可以使用NC这个基本网络工具,提高性能。同时使用qpress作为压缩算法。

执行上面的命令需要2.8s。平均吞吐量为402MB/s,比使用Gzip+Scp快了16倍!!

根据上文的公式,和自己的数据,可以绘出上面的表格,就可以选择出最适合的压缩算法和传输方式。达到满意的效果。如果是一个长期运行的脚本的话,这么做是值得的。

refer to:http://www.yankay.com/linux%E5%A4%A7%E6%96%87%E4%BB%B6%E4%BC%A0%E8%BE%93/

Tagged on:

Leave a Reply

Your email address will not be published. Required fields are marked *