☰

为什么我的 rsync 这么慢？

tag-icon • tag-icon linux performance rsync
为什么我的 rsync 这么慢？

我的笔记本电脑和工作站都连接到千兆交换机。两者都运行 Linux。但是当我使用 复制文件时rsync，它的性能很差。

我的速度大约是 22 MB/s。理论上我不应该达到 125 MB/s 吗？这里的限制因素是什么？

编辑：我进行了一些实验。

笔记本电脑上的写入性能

笔记本电脑具有带全盘加密的 xfs 文件系统。它使用aes-cbc-essiv:sha256密钥长度为 256 位的密码模式。磁盘写入性能58.8 MB/秒。

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 上。RAID 顶部是 lvm。卷本身使用相同的密码加密。工作站有一个 FX-8150 CPU，它有一个原生 AES-NI 指令集，可以加快加密速度。磁盘读取性能256 MB/秒（缓存很冷）。

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 兆比特/秒

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

答案1

另一种缓解高 CPU 使用率但仍保留 rsync 功能的方法是从 rsync/SSH 移至 rsync/NFS。您可以通过 NFS 导出要复制的路径，然后从 NFS 安装到目标位置本地使用 rsync。

在对 WD MyBook Live 网络磁盘进行的一次测试中，千兆网络上的 NAS 向 2 个本地 USB 磁盘进行的一次或多次 rsync 复制速度不会超过 10MB/秒（CPU：80% 用户，20% 系统），在通过 NFS 导出并从 NFS 共享本地 rsync 到两个磁盘后，我总共获得了 45MB/秒（最大化两个 USB2 磁盘）且 CPU 使用率很低。使用 rsync/SSH 时的磁盘利用率约为 6%，使用 rsync/NFS 时的磁盘利用率接近 24%，而两个 USB2 磁盘的利用率接近 100%。

因此，我们有效地将瓶颈从 NAS CPU 转移到两个 USB2 磁盘。

答案2

原因可能包括：压缩、加密、正在复制的文件的数量和大小、源和目标系统的磁盘 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 进入笔记本电脑。您真正的性能期望是什么？

答案3

经过更多测试，我终于自己找到了答案。rsync默认情况下使用 ssh 隧道。加密会使其变慢。所以我需要绕过加密的东西。

解决方案 1：设置 rsync 服务器

要通过协议使用它rsync，您必须设置一个 rsyncd 服务器。/etc/init.d/rsync我的笔记本电脑上有一个脚本，所以我猜 rsyncd 正在运行。我错了。/etc/init.d/rsync start当 中未启用 rsync 时，它会默默存在/etc/default/rsync。然后您还必须在 中对其进行配置/etc/rsyncd.conf，这很麻烦。

如果你完成了所有这些，你必须使用rsync file.foo user@machine::directory。请注意，两个冒号。

解决方案 2：老式 rsh-server

但是，配置对我来说太复杂了。所以我只是rsh-server在笔记本电脑上安装了。然后在工作站上调用 rsync，-e rexec使用 rsh 而不是 ssh。这几乎使性能翻了一番44.6 MB/秒，速度仍然很慢。速度在58 MB/秒和33 MB/秒，这表明可能存在一些缓冲区或拥塞控制问题。但这超出了这个问题的范围。

答案4

这些都是非常古老的问题和答案，但缺少一个重要的事情：如果您正在复制已压缩或加密的数据，请关闭压缩。

如果您的数据既未压缩也未加密，您仍然只想压缩一次！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 请求，即使请求来自不同的接口。

相关内容