tar+lz4/pigz+ssh更快的数据传输

1. 结论

使用tar+lz4+ssh的方式能够获得最大的传输性能:

 代码如下 复制代码

time tar -c sendlog/|pv|lz4 -B4|ssh -c arcfour128 
-o"MACs umac-64@openssh.com" 10.xxx.xxx.36 "lz4 -d |tar -xC /u01/backup_supu"
3.91GiB 0:00:16 [ 249MiB/s]

real 0m16.067s
user 0m15.553s
sys 0m16.821s249MB/s,

妥妥的。是最原始scp(40MB/s)的6倍,原来400GB传输需要约3小时,现在只需要27分钟了。

注1:lz4在解压方面的优异表现,使得他在本案例中非常重要。如果无需解压的传输,则可以考虑使用pigz/pbiz2

注2:使用pv观察,网络流量约80MB,所以使用nc替换ssh并不会有明显的性能提升

注3:lz4压缩使用-B4(64KB块大小),解压使用-B7(4MB块大小),是本案例的测试最优值
2. 关于lz4
lz4是一个让"人见人爱、花见花开"的压缩算法,能够在多核上很好的扩展,压缩速度和压缩比并没有太大优势(pigz),但是他的解压速度非常惊人,本案例测试lz4的解压是gunzip的3倍(更多的对比测试)。因为压缩时高效的多核利用,再加上惊艳的解压,lz4已经在非常多重要场合使用了:Linux3.11内核实现了LZ4,并可以使用其压缩和解压kernel image HBase:Add an LZ4 compression option to HFile等等(参考)。

对于需要频繁压缩、实时快速解压的场景来说,lz4非常适合。

3. 性能环境说明

这里使用同上一篇文章相同的两台主机环境:ping获得RTT是17ms;使用iperf测试带宽是115MB(参考附录);

整个过程有几个阶段:磁盘读取-->打包(tar)-->压缩-->传输-->解压缩-->拆包-->落盘 对应了的速度测试:

3.1 磁盘读取和落盘
磁盘读取(有page cache),能到3GB/s;磁盘写入约428MB:

 代码如下 复制代码

# dd if=./sendlog.tar of=/dev/null bs=4096 count=1048576
1024002+1 records in
1024002+1 records out
4194314240 bytes (4.2 GB) copied, 1.33946 s, 3.1 GB/s

# dd if=/dev/zero of=./x.zero.file bs=4096 count=1048576
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 10.0306 s, 428 MB/s3.2

打包、拆包
打包和拆包速度都大于350MB/s:

 代码如下 复制代码

# time tar -cf sendlog.tar ./sendlog/
real 0m10.996s
# time tar -xf sendlog.tar
real 0m11.564s3.3

压缩、解压缩
关于各个压缩工具的性能(压缩、解压、压缩率)已经有很多人做了比较,本文不做详细讨论,这里选择gzip/pigz lz4 bzip做本测试的比较:

 代码如下 复制代码

           | input speed | output speed | rate   | speed of decoder
pigz -p 16 | 327.0MB/s   | 57.2MB/s     | 17.5%  | 95  MB/s
lz4        | 288.0MB/s   | 79.2MB/s     | 27.5%  | 264 MB/s
bzip2      |   4.9MB/s   | 0.65MB/s     | 13.1%  | 25.6MB /s压缩工具的比较测试参考:Gzip vs Bzip2 vs LZMA vs XZ vs LZ4 vs LZO

可以看到,lz4在压缩率上略微逊色(对比pigz),但是在解压速度上有这惊人的优势。

3.4 传输

前文介绍了scp,约90MB最快的传输速度。

3.5 整体流程

 代码如下 复制代码
磁盘读取---->打包---->压缩------>传输---->解压缩-->拆包---->落盘
             |->tar   |->gzip    |->ssh   |->gzip  |->tar
                      |->bzip2   |->http  |->bzip
                      |-> ...    |->nc    |->...
                      |->lz4              |->lz4
>400MB/s    >350MB/s  79MB/s     90MB/s   72MB/s    >350MB/s >400MB/s

这里可以看到,解压是最大的瓶颈,使用在解压方面最有优势的压缩工具,能让传输获得最大速度。而lz4正是在解压效率方面有着巨大的优势。

按照上面lz4的测试,传输速度理论值为264MB/s(此时传输速度为264*27.3%=72MB),这也是本次测试的理论上限速度。

4. 实验测试
使用lz4压缩传输:

 代码如下 复制代码

# time tar -c sendlog/|lz4|ssh -c arcfour128
 -o"MACs umac-64@openssh.com" 10.xxx.xx.36 "lz4 -d |tar -xC /u01/backup_supu"
real 0m25.646s
real 0m25.911s
real 0m29.019s

测试三次,分别耗时26s、29s、25.6s,传输的平均速度为:152MB/s,网络带宽占用约41.9MB/s。

使用pigz的压缩传输:

 代码如下 复制代码

# time tar -c sendlog/|pigz -p 16|ssh -c arcfour128
 -o"MACs umac-64@openssh.com" 10.xxx.xx.36 "gzip -d|tar -xC /u01/backup_supu"
rreal 0m37.030s
real 0m25.911s
real 0m29.019s

测试三次,分别耗时37s、37.2s、35.6s,传输的平均速度为:110.7MB/s,网络带宽占用约19.4MB/s。

对比发现,在压缩方面pigz与lz4并没有太大区别,但是lz4解压速度非常快,所以在这种需要立刻解压的场景下,lz4轻松胜出(bzip2这种就不需要测试了)。

4.1 分析
按照第二节中的理论分析,传输速度应该能到260MB,但是上面只有152MB/s,这说明,还有调优的空间。继续分析,看看瓶颈在哪儿:

使用pv工具观察到,tar+lz4有约70MB/s的输出:

 time tar -c sendlog/|lz4|pv > /dev/null
1.02GiB 0:00:14 [70.8MiB/s] [                                 <=>]比直接lz4输出,要慢了10%左右(lz约79MB/s)。

再加上一次网络ssh:

time tar -c sendlog/|lz4|pv|ssh -c arcfour128 -o "MACs umac-64@openssh.com" 10.xxx.xxx.36 "cat - >/dev/null"
1.02GiB 0:00:23 [43.9MiB/s] [                                 <=>]

比直接lz4输出,要慢了45%左右(lz约79MB/s);远端再加上解压和拆包,压缩后的传输速度就是41.9MB/s。为什么会下降,还不明了,作者也还没有想到有什么方法能够直接加速这样的管道传输,如果看客有什么建议,不妨分享,看看还能不能优化,继续提升速度。

至此,传输速度就能够到150MB/s。比最原始scp(40MB/s)要快了约4倍,原来400GB需要约3小时,现在只需要45分钟了。

5. lz4参数测试

前面试验发现,整个流程中lz4压缩比预期的要慢45%左右,而这里区别仅仅是一个使用管道(pipe)、一个直接读取。这里尝试通过修改lz4块大小对比,是否有性能提升:

测试命令:

 代码如下 复制代码

for i in `seq 4 7`; do time tar -c ./sendlog/|lz4 -B$i |pv > /dev/null ;done
1.07GiB 0:00:11 [94.4MiB/s] [                          <=>]
real 0m11.640s
user 0m10.375s
sys 0m4.308s

可以看到块大小为64KB的时候,lz的压缩速度有显著提升(31%)。于是,我们在lz4新增参数-B4,看看是否能够提升性能:

Bang!确实,传输性能提升到了约249MB/s:

 代码如下 复制代码

time tar -c sendlog/|pv|lz4 -B4|ssh -c arcfour128 
-o"MACs umac-64@openssh.com" 10.xxx.xxx.36 "lz4 -d |tar -xC /u01/backup_supu"
3.91GiB 0:00:16 [ 249MiB/s]

real 0m16.067s
user 0m15.553s
sys 0m16.821s5.

 

为什么不用nc
就不用它!!!

* nc不比ssh快;如果压缩后传输,nc比ssh没有优势

* nc在脚本中不好调用,需要在两端执行命令

* nc需要一个额外的网络端口

* nc不加密

6. 还能不能更快
本案例中,lz4解压缩的速度是264MB/s,这里能够达到249MB/s,应该还有一点点可以榨取,不过我已经没有招了。

附录
iperf的带宽测试:

 代码如下 复制代码

iperf -c 10.xxx.xx.18 -p 3999 -t 30
------------------------------------------------------------
Client connecting to 10.xxx.xx.18, TCP port 3999
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.xx.xx.36 port 43838 connected with 10.xx.xx.18 port 3999
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-30.0 sec  3.15 GBytes   903 Mbits/sec

iperf -s -p 3999 -m
------------------------------------------------------------
Server listening on TCP port 3999
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.xx.xx.18 port 3999 connected with 10.xx.xx.36 port 43838
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.0 sec  3.15 GBytes   902 Mbits/sec
[  4] MSS size 1448 bytes (MTU 1500 bytes, ethernet)

时间: 2024-08-03 08:14:41

tar+lz4/pigz+ssh更快的数据传输的相关文章

使用tar+lz4/pigz+ssh更快的数据传输

1. 结论 使用tar+lz4+ssh的方式能够获得最大的传输性能: time tar -c sendlog/|pv|lz4 -B4|ssh -c arcfour128 \ -o"MACs umac-64@openssh.com" 10.xxx.xxx.36 "lz4 -d |tar -xC /u01/backup_supu" 3.91GiB 0:00:16 [ 249MiB/s] real 0m16.067s user 0m15.553s sys 0m16.821

让跨国公司数据传输更快,Viptela用SD-WAN技术提供广域网服务

Viptela是一家提供虚拟广域网技术的公司,致力于使用SD-WAN技术为跨国企业提供更安全可控.性价比更高的网络服务. 具体来说,企业可以通过购买Viptela的许可证进行虚拟网络线路的快速部署,也可以直接购买其硬件设备,只要设备接通了电源及网络,就能自动接入Viptela云端,进行识别认证后便可接入Viptela的线路.Viptela称,除了记录网络地址,其云服务不会读取和存储用户的任何信息. 目前Viptela的三种设备vEdge100.vEdge1000和vEdge2000可分别提供10

发展4G让大家享受更快的网速

短短几年的时间,从3G到4G,这一步走得太快太超前了吗?据了解:2020年,中国手机用户将超过15亿户,数据业务量是现在的1000倍甚至更多:未来5年,全球移动数据流量将增长约26倍.这意味着,随着各种功能强大的智能终端的出现和普及,现在任何一家运营商的网络,都会如同早高峰最堵车的红灯口,被海量的数据传输请求瞬间挤爆.这种情况,在处于高速发展中的中国移动通信领域将尤为严峻. 与此同时,由于带宽和速度的限制,目前的3G网络无法满足高清视频传输的要求.而4G网络理论速率可达到下载100兆比特/秒.上

千招百式:让你的ADSL跑得更快_网络冲浪

通过ADSL拨号上网,已经成为众多个人用户的首选上网途径.尽管这种上网方式,要比传统的电话拨号上网速度快许多,不过这种速度离真正的宽带速度还有一定的距离.当然,如果我们能开动脑筋,从挖掘ADSL自身的潜力出发,还是有办法让ADSL跑得更快,甚至让其速度接近真正的宽带速度.不信的话,就请各位一起来看看下面的ADSl优化招法,相信在这些方法的指导下,ADSL上网速度要比平时快许多. 1.启用数据分包功能 大家知道,如果在网上传输大容量数据信息时,你会发现ADSL此时的上网速度将非常缓慢:相反,如果你

360安全浏览器-更快的网页下载速度

  360安全浏览器在浏览的各个方面进行优化以提高浏览速度,它比IE等同类浏览器具有更快的下载速度,这需要您自己的使用体验. 从技术上讲,大致有如下几个重要的环节进行了浏览优化: 1.扁平的模块封装,减少代码环节,节省CPU占用 2.特别为浏览器优化的OLE容器,减少不必要的接口和处理过程,节省CPU占用 3.独特的ActiveX控件自动安装过滤,停止浏览器自动下载控件的过程,节省网络带宽 4.增强的页面元素黑名单过滤,不同于标准接口的一般实现方法,在增强速度的同时,不影响界面美观,过滤掉的元素

Android版Chrome支持更快的安全加密算法

谷歌最近通过控制浏览器及其访问的站点来加速Android平台安全网页的浏览--谷歌anti-abuse研究团队主管Elie Bursztein在本周四的博客文章中表示,谷歌推行了更快的新型加密算法,这两种名为ChaCha20和Poly1305的加密算法加入到了Chrome浏览器中. Bursztein表示:"ChaCha20和Poly1305在移动和可穿戴设备上会显得非常快."部分原因就在于这些算法能够利用ARM芯片中的部分加速特性.而且此类算法能够有效防止数据窃听,包括来自政府的监控

优化JS和CSS更快地下载网页图片

文章简介:我关注JS和CSS的重点也是如何能够更快地下载图片.图片是用户可以直观看到的.他们并不会关注JS和CSS.确实,JS和CSS会影响图片内容的展示,尤其是会影响图片的展示方式(比如图片轮播,CSS背景图和媒体查询).但是我认为JS和CSS只是展示图片的方式.在页面加载的过程 我的大部分性能优化工作都集中在JavaScript和CSS上,从早期的Move Scripts to the Bottom和Put Stylesheets at the Top规则.为了强调这些规则的重要性,我甚至说

让你的 PHP 7 更快 (GCC PGO)

我们一直致力于提升PHP7的性能,  上个月我们注意到GCC的PGO能在Wordpress上能带来近10%的性能提升,  这个让我们很激动. 然而,  PGO正如名字所说(Profile Guided Optimization 有兴趣的可以Google), 他需要用一些用例来获得反馈, 也就是说这个优化是需要和一个特定的场景绑定的. 你对一个场景的优化, 也许在另外一个场景就事与愿违了.  它不是一个通用的优化. 所以我们不能简单的就包含这些优化, 也无法直接发布PGO编译后的PHP7. 当然,

更快更安全更稳定 OpenDNS上网新方式

无论你何时使用Internet,都会用到DNS.每次发送电子邮件或是在网上冲浪,你都必须依赖DNS.DNS负责主机名字之间和互联网络地址之间的映射,是由计算机来处理的,要是连接DNS服务器的过程出现延迟,或者如果DNS服务器解析某个地址时间过长,那么访问就会出现延迟.而如果能够以某种方式加快域名解析,就能够加快上网冲浪的速度,下面介绍的是一种加速方法:使用OpenDNS. 一.OpenDNS的特点有三个: 1.OpenDNS具有更安全的特点.OpenDN可以识别和阻止钓鱼(Phishing)网站