我的笔记本电脑和我的工作站都连接到千兆交换机。 两者都在运行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这样的arcfourencryption密码来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.confconfiguration它，这很痛苦。
如果你完成了所有这些，你必须使用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请求，即使请求是在不同的接口上进行的。