ibl*_*lue 49 linux performance rsync
我的笔记本电脑和工作站都连接到千兆交换机。两者都运行Linux。但是当我用 复制文件时rsync，它的性能很差。
我得到大约 22 MB/s。理论上我不应该得到大约 125 MB/s 吗？这里的限制因素是什么？
编辑：我进行了一些实验。
笔记本电脑有一个全盘加密的 xfs 文件系统。它使用aes-cbc-essiv:sha256密码模式，密钥长度为 256 位。磁盘写入性能为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 个 HDD 的软件 RAID-5 上。在raid之上是一个lvm。卷本身使用相同的密码加密。工作站有一个 FX-8150 cpu，它有一个本地 AES-NI 指令集，可以加速加密。磁盘读取性能为256 MB/s（缓存是冷的）。
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。网络性能为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
eww*_*ite 27
原因可能包括：压缩、加密、被复制文件的数量和大小、源和目标系统的磁盘 I/O 能力、TCP 开销……这些都是会影响您进行的传输类型的因素。
请发布您正在使用的 rsync 命令并提供有关两台计算机规格的详细信息。
编辑：加密通常是 rsync 速度的限制因素。您可以使用 ssh 和更轻量级的加密密码运行，例如arcfour
就像是： rsync -e "ssh -c arcfour"
或者您可以使用可以禁用加密的修改后的 rsync/ssh。请参阅 hpn-ssh：http ://psc.edu/networking/projects/hpn-ssh
但同样，与工作站相比，您的笔记本电脑的驱动器速度较慢。写入可能会被阻止并等待 I/O 进入您的笔记本电脑。您的实际性能期望是什么？
小智 21
另一种缓解高 CPU 使用率但仍保留 rsync 功能的方法是从 rsync/SSH 移动到 rsync/NFS。您可以通过 NFS 导出要从中复制的路径，然后在本地使用 rsync 从 NFS 挂载到目标位置。
在 WD MyBook Live 网络磁盘的一项测试中，从千兆网络上的 NAS 向 2 个本地 USB 磁盘的一个或多个 rsync 复制不会超过 10MB/秒（CPU：80% usr，20% sys），导出后NFS 和本地从 NFS 共享到两个磁盘的 rsync 我总共获得了 45MB/秒（最大化两个 USB2 磁盘）和很少的 CPU 使用率。使用 rsync/SSH 时的磁盘利用率约为 6%，使用 rsync/NFS 时接近 24%，而两个 USB2 磁盘都接近 100%。
因此，我们有效地将瓶颈从 NAS CPU 转移到了两个 USB2 磁盘。
ibl*_*lue 11
经过更多的测试，我终于自己找到了答案。rsync默认情况下通过 ssh 使用隧道。加密使它变慢。所以我需要绕过那些加密的东西。
要通过rsync协议使用它，您必须设置一个 rsyncd 服务器。/etc/init.d/rsync我的笔记本电脑上有一个脚本，所以我猜，rsyncd 正在运行。我错了。/etc/init.d/rsync start当 .rsync 中未启用 rsync 时，静默存在/etc/default/rsync。然后你还必须在 中配置它/etc/rsyncd.conf，这很痛苦。
如果你完成了这一切，你必须使用rsync file.foo user@machine::directory. 请注意，有两个冒号。
但是，配置对我来说太复杂了。所以我刚刚安装并安装rsh-server在我的笔记本电脑上。在工作站上调用 rsync-e rexec然后使用 rsh 而不是 ssh。然后将性能几乎翻了一番，达到44.6 MB/s，这仍然很慢。速度在58 MB/s和33 MB/s之间反弹，这表明可能存在一些缓冲区或拥塞控制问题。但这超出了这个问题的范围。
这是一个非常古老的问题和答案，但缺少一件重要的事情：如果您正在复制已压缩或加密的数据，请关闭压缩。
如果您的数据既未压缩也未加密，您仍然只想压缩一次！Rsync 使用 -z 压缩，ssh 使用 -C 压缩（可能是默认设置）。由于我的数据被压缩，我还没有测试哪个更好。
当我在做的时候，你可以关闭 X 转发和 TTY 分配，导致：
rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst
最后，确保（例如使用iptraf）您实际上正在使用您认为正在使用的网络接口。我非常惊讶地注意到，在我的 OSX 上，传出 ssh 绑定到默认传出接口上的 IP，而不是绑定到数据包应该被路由出去的接口上的 IP。我的两台笔记本电脑之间的直接 GB 交叉连接也没有使用 WiFi 连接。经过调查，这是由于使用 169.254/16，Mac 将其放在所有接口上，并且即使请求来自不同的接口，目标计算机也会回复 ARP 请求。