我的笔记本电脑和我的工作站都连接到千兆交换机。 两者都在运行Linux。 但是,当我用rsync
复制文件,它performance不佳。
我得到约22 MB /秒。 我理论上不应该达到125 MB / s? 这里的限制因素是什么?
编辑:我进行了一些实验。
笔记本电脑有一个全磁盘encryption的xfs文件系统。 它使用密钥长度为256位的aes-cbc-essiv:sha256
密码模式。 磁盘写入性能是58.8 MB / s 。
iblue@nerdpol:~$ LANG=C dd if=/dev/zero of=test.img bs=1M count=1024 1073741824 Bytes (1.1 GB) copied, 18.2735 s, 58.8 MB/s
我复制的文件在5个硬盘上的软件RAID-5上。 在突袭之上是一个lvm。 卷本身使用相同的密码encryption。 该工作站有一个FX-8150 CPU,具有加速encryption的本机AES-NI指令集。 磁盘读取性能是256 MB / s (caching是冷的)。
iblue@raven:/mnt/bytemachine/imgs$ dd if=backup-1333796266.tar.bz2 of=/dev/null bs=1M 10213172008 bytes (10 GB) copied, 39.8882 s, 256 MB/s
我在两个客户端之间运行了iperf。 networking性能是939 Mbit / s
iblue@raven $ iperf -c 94.135.XXX ------------------------------------------------------------ Client connecting to 94.135.XXX, TCP port 5001 TCP window size: 23.2 KByte (default) ------------------------------------------------------------ [ 3] local 94.135.XXX port 59385 connected with 94.135.YYY port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec
另一种缓解高CPU使用率但仍然保持rsyncfunction的方法是从rsync / SSH移到rsync / NFS。 您可以通过NFS导出要复制的path,然后使用本地NFS从NFS装载到目标位置。
在WD MyBook Livenetworking磁盘的testing中,千兆networking上朝向2个本地USB磁盘的NAS的一个或多个rsyncs在导出后不会复制超过10MB /秒(CPU:80%usr,20%sys)从NFS共享本地NFS和rsyncing到两个磁盘我总共有45MB /秒(两个USB2磁盘最大)和很less的CPU使用率。 使用rsync / SSH时的磁盘利用率大约是6%,使用rsync / NFS时接近24%,而两个USB2磁盘接近100%。
所以我们有效地把NAS CPU的瓶颈移到了两个USB2磁盘上。
原因可能包括:压缩,encryption,被复制文件的数量和大小,源系统和目标系统的磁盘I / O能力,TCP开销……这些都是可能影响您正在进行的传输types的因素。
请发布您正在使用的rsync命令,并提供有关两台计算机规格的详细信息。
编辑:encryption通常是rsync速度的限制因素。 你可以用ssh和一个像arcfour
这样的arcfour
encryption密码来arcfour
例如: rsync -e "ssh -c arcfour"
或者你可以使用修改的rsync / ssh来禁用encryption。 请参阅hpn-ssh: http ://psc.edu/networking/projects/hpn-ssh
但是,与您的工作站相比,您的笔记本电脑的运行缓慢。 写入可能被阻止,并等待I / O进入你的笔记本电脑。 你真正的performance期望是什么?
经过多次testing,我终于自己find了答案。 rsync
默认使用通过ssh的隧道。 密码使其变慢。 所以我需要绕过密码的东西。
要通过rsync
协议使用它,你必须build立一个rsyncd服务器。 我的笔记本电脑上有一个/etc/init.d/rsync
脚本,所以我猜测,rsyncd正在运行。 我错了。 在/etc/default/rsync
未启用rsync时, /etc/default/rsync
/etc/init.d/rsync start
/etc/default/rsync
/etc/init.d/rsync start
将以静默方式存在。 那么你也必须在/etc/rsyncd.conf
configuration它,这很痛苦。
如果你完成了所有这些,你必须使用rsync file.foo user@machine::directory
。 请注意,有两个冒号 。
但是,configuration对我来说太复杂了。 所以我只是在我的笔记本电脑上安装了rsh-server
。 使用-e rexec
在工作站上调用rsync,然后使用rsh而不是ssh。 然后,性能提高了将近一倍,达到了44.6 MB / s ,但仍然很慢。 速度在58 MB / s和33 MB / s之间反弹,这表示可能存在缓冲区或拥塞控制问题。 但这超出了这个问题的范围。
这是一个非常古老的问题和答案,但是缺less一个重要的东西:如果您要复制已压缩或已encryption的数据,请closures压缩。
如果你的数据既没有压缩也没有encryption,你仍然只想压缩一次! Rsync使用-z压缩,ssh使用-C压缩(可能是默认情况下)。 我没有testing过,因为我的数据是压缩的更好。
当我在这里,你可以closuresX转发和TTY分配,导致:
rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst
最后,确保(例如使用iptraf
)确实使用您认为正在使用的networking接口。 我非常惊讶地注意到,在我的OSX上,传出的ssh绑定到默认传出接口上的IP,而不是数据包应该被路由到的接口上的IP。 两台笔记本电脑之间的直接GB交叉连接也没有被使用。 经过调查,这是因为Mac使用了169.254 / 16(所有的接口),而目的地计算机回复ARP请求,即使请求是在不同的接口上进行的。