• 首页
  • 关于

我自然

每月存档:2月 2012

Linux大文件传输

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

复制文件

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

使用ZIP+SCP

我们可以通过ZIP+SCP的组合实现这个功能。
gzip -c /home/yankay/data | ssh yankay01 "gunzip -c - > /home/yankay/data"

这条命令是将/home/yankay/data经过GZIP压缩,通过ssh传输到yankay01的机器上。

data文件的大小是1.1GB,经过Zip压缩后是183MB,执行上面的命令需要45.6s。平均吞吐量为24.7MB/s
我们会发现Scp也有压缩功能,所以上面的语句可以写成
scp -C -c blowfish /home/yankay/data yankay01:/home/yankay/data

这样运行效果是相同的,不通之处在于我使用了blowfish算法作为Scp的密匙算法,使用这个算法可以比默认的情况快很多。单单对与scp,使用了blowfish 吞吐量是62MB/s,不使用只有46MB/s。

可是我执行上面一条命令的时候,发现还是需要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作为压缩算法。

scp /usr/bin/qpress yankay01:/usr/bin/qpress
ssh yankay01 "nc -l 12345 |  qpress -dio > /home/yankay/data" &
qpress -o /home/yankay/data |nc yankay01 12345

第一行是将gpress安装到远程机器上,第二行在远程机器上使用nc监听一个端口,第三行压缩并传送数据。

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

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

文章分类 软件技术 | 标签: Linux, 传输, 大文件 | 发表评论 |

内存究竟有多快?

在 2012年2月6日 上公布 作者为 yankay

一般来说。CPU需要0个周期来访问其寄存器,1-30个周期来访问高速缓存,50-200个周期来访问主存。

对于Intel Core i7来说。这个值可以很具体。Intel Core i7的主频约在2-3GHz。可以计算出。

L1—指令缓存 L1-数据缓存 L2-缓存 L3-缓存 内存
访问周期 4 4 11 30-40 50-200
缓存大小 32KB 32KB 256KB 8MB 若干GB
访问时间 2ns 2ns 5ns 14-18ns 24-93ns

也就是说,访问内存的时间是ns级别的。

再来看看磁盘。

磁盘的访问时间=寻道时间+旋转延迟+数据传输时间。对于普通的7200转SATA磁盘。这个值是:9ms+4ms+0.02ms=13.02ms。

也就是说,如果从磁盘随机访问一个字节,需要13.02ms,比从内存获取的时间24-93ns,至少要多14万倍。相差5个数据级,何其巨大的差距。

顺序读写磁盘会快一些。 假设一个盘片有1000个扇区,每个扇区512字节,7200转。顺序读可以忽略掉寻道的时间。所以吞吐量是 扇区数×扇区大小×转速=1000*512/(60/7200)=58MB/s。这个数据似乎不咋样。如果使用多盘系统。SATA II的接口,吞吐量可以达到300MB/s。追求极限性能可以mount裸盘直接操作多盘。

存储器山

《深入理解计算机系统》一书中提到了一个存储器山的概念。教授先生别出心裁的将存储器的吞吐量,画成了一座山。

 

存储器山的测试程序是这样的:

Kernel_loop(elems, stride):
for (i = 0; i < elems; i += stride)
    result = data[i];

X轴表示的是读取步长,Y轴是吞吐量,Z轴是数据总量的大小。

可以看出来步长越小,数据数据总量越小。性能越好。

很明显,山是不是平滑的,是成阶梯状。红色部分为L1缓存,绿色为L2缓存,浅蓝是L3缓存,深蓝是内存。我们可以得一些数据。

L1-数据缓存 L2-缓存 L3-缓存 内存 磁盘 SSD
缓存大小 32KB 256KB 8MB 十几GB 几TB 几百GB
访问时间 2ns 5ns 14-18ns 24-93ns 13.0ms 30-300us
吞吐量 6500MB/s 3300MB/s 2200MB/s 800MB/s 60MB/s 250MB/s

也就是说,去除高速缓存的内存,吞吐量性能只有800MB/s而已。比起磁盘的300MB/s,网络的100MB/s。也只是快了几倍。平时说内存比磁盘快许多,其实没有那么多,如果不好好操作内存,内存的频繁读写,也可以成为系统瓶颈。

总结

现在处理器的主频已经停止了增长。但是高速缓存仍然以摩尔定律的速度增长的。长久的看,高速缓存频率逐渐会追上处理器的性能,容量也会越来越大。但是内存则不容乐观,虽然容量增加了许多,但是性能确没有大的提升,磁盘的状况也是类似;SSD刚刚开始普及,趋势不明显。

但可以看到,SSD的吞吐量和内存的吞吐量相去并不大。也就是说在未来,当SSD完全替代了磁盘。我们要像现在操作磁盘一样小心翼翼地操作内存,才有可能写出符合那个时代计算机性能的程序。相比之下,SSD的使用比磁盘要轻松一些,毕竟随机读写的速度在一两个数量级上。

文章分类 软件技术 | 标签: 内存, 性能 | 5 评论 |

近期文章

  • 听说 Docker 被 kubenetes 抛弃了,怎么办?containerd
  • 公告 – 博客重开了
  • CloudFoundry v2面面谈,内赠MicroCFv2福利
  • Docker能够运行任何应用的“PaaS”云
  • Scala Tour – 精选

近期评论

  • Gao发表在《公告 – 博客重开了》
  • Impala:新一代开源大数据分析引擎 – FIXBBS发表在《Google Dremel 原理 – 如何能3秒分析1PB》
  • 何建兵发表在《NoSQL数据库笔谈v0.2》
  • Pony发表在《Docker能够运行任何应用的“PaaS”云》
  • Pony发表在《Docker能够运行任何应用的“PaaS”云》

归档

  • 2021年6月
  • 2021年3月
  • 2014年2月
  • 2013年9月
  • 2013年5月
  • 2013年1月
  • 2012年11月
  • 2012年9月
  • 2012年8月
  • 2012年3月
  • 2012年2月
  • 2012年1月
  • 2011年11月
  • 2011年10月
  • 2011年9月
  • 2010年10月
  • 2010年8月
  • 2010年7月
  • 2010年6月
  • 2010年5月
  • 2010年4月
  • 2010年3月
  • 2010年2月
  • 2010年1月
  • 2009年10月
  • 2009年9月
  • 2009年8月
  • 2009年7月
  • 2009年6月
  • 2008年10月
  • 2008年8月
  • 2008年7月
  • 2008年6月

分类

  • 家庭生活
  • 未分类
  • 每日心得
  • 软件技术

友情链接

  • DaoCloud Enterprise
  • DaoCloud 云原生一体机

CyberChimps WordPress Themes

沪ICP备2021008917号-1 © 颜开