用 bbcp 取代 scp

0. 前言

bbcp 是由SLAC(斯坦福直线加速器中心)的Andy Hanushevsky创立的点对点网络文件拷贝工具。经过简单测试,发现速度比 scp 快了10倍左右,因此推荐大家采用bbcp来取代scp等老家伙 :)

1. 安装

 

访问bbcp的主页:http://www.slac.stanford.edu/~abh/bbcp/,下载对应二进制版本或者源码,如果是源码,就需要自己编译;这里我选择的是二进制版本,省事。我的系统平台是 Linux 2.6.9-67.0.15.ELsmp x86_64,因此选择了:Redhat Linux RHEL4 (Nahant 2.6.9-67-ELsmp amd64_linux26)。下载回来后,直接放到 /usr/local/bin 下面:

mv bbcp.amd64_linux26 /usr/local/bin/bbcp && chmod +x /usr/local/bin/bbcp

然后就可以开始用了。
注意:如果你的服务器启用防火墙了,注意需要开放 5031 端口的 INPUT 链。例如,要从 192.168.0.84 拷贝文件到 192.168.0.85,则做如下规则:

iptables -I INPUT -s 192.168.0.85 -p tcp --dport 5031 -j ACCEPT

另外,bbcp拷贝的目标段也需要安装bbcp。

2. 测试

本次测试都是拷贝1G的文件。

2.1 测试 scp

time scp 1Gfile 192.168.0.85:/home/yejr/
1Gfile                                100% 1024MB  10.2MB/s   01:40
real    1m40.933s
user    1m34.360s
sys     0m6.497s 

 

2.2 测试 bbcp

time bbcp -4 -v -s 16 -F -f -w 256k ibdata1 root@192.168.0.85:/home/update/
bbcp: Resource temporarily unavailable obtaining address for 192.168.0.84
bbcp: Resource temporarily unavailable obtaining address for 192.168.0.84
bbcp: Resource temporarily unavailable obtaining address for 192.168.0.85
bbcp: Resource temporarily unavailable obtaining address for 192.168.0.85
bbcp: Resource temporarily unavailable obtaining address for 192.168.0.84
bbcp: Resource temporarily unavailable obtaining address for 192.168.0.84
bbcp: 192.168.0.84 kernel using a send window size of 524352 not 262176
File /home/update/ibdata1 created; 1073741824 bytes at 115788.0 KB/s
1 file copied at effectively 103737.2 KB/s
real    0m10.111s
user    0m0.031s
sys     0m2.767s

拷贝目录,只需要多加一个 -r 参数即可:

bbcp -4 -r -v -s 16 -F -f -w 256k mysql root@192.168.0.85:/data/

更多详细信息请查看:Using BBCP 和上面提到的bbcp主页。

技术相关:

评论

我测试了100M左右的文件,两台服务器都是Red Hat Enterprise Linux AS release 4 (Nahant Update 4)。速度没有scp快啊。
time /usr/bin/scp a.tar.gz 172.16.103.32:/data/soft/soft/
real 0m16.597s
user 0m4.870s
sys 0m6.480s
time bbcp -v -s 16 -F -f -w 256k a.tar.gz 172.16.103.32:/data/soft/
real 0m38.143s
user 0m0.033s
sys 0m2.505s

1. 确保你2次测试时,这2个机器上都没有其他额外io

2. 确保当时2次测试时网络状况都是良好的

3. 检查2次测试之间的环境差异

4. 如果上面都没问题,那请继续检查你的rpwt,哈哈

MySQL方案、培训、支持

我觉得这个东西作用不是特别大。
比如说公网上传输场景中我们很难突破硬性的带宽限制
而内网呢?如果是100M的网络,传几个G的文件SCP也用不了多大会,如果更大的肯定会选择别的方式了。
其实SCP已经比较接近于理论最高速率。

呵呵,照你的说法,就不会出现我上面测试的scp和bbcp对比相差那么大的结果了。scp是单线程拷贝的,而bbcp是实现多线程,并且采用移动窗口的机制实现,相同条件下会比较快。你说的硬性带宽限制当然没错,但总有需要拷贝一个大文件这种需求,这时候就很实用了。但在大量并发拷文件的情景下用处当然不大。

MySQL方案、培训、支持

我也觉得没有必要。

你就差那几秒钟。费神去提高一些牛角尖的问题。何必呢。

哈哈,尝试新思路,不算钻牛角尖吧 :)

MySQL方案、培训、支持

1.无须加密肯定快些
2.多线程肯定快些
而且差的不是几秒呦~10倍!!!大的数据迁移正好需要此等神器~谢谢楼主~

当需要传输的数据是百GB级别,而且同时分发到N台集群机器上时,bbcp就有用多了。
目前我们搜索系统索引就采用bbcp来分发。

是的,今天我也要传输572G文件,跨IDC但有落纤(不限速)服务器千兆网络下,耗时99分钟。在同一个VLAN内传输,耗时应该不到60分钟,速度还是非常可观的。