为什么rsync比NFS快？

几天前，我注意到了一件相当奇怪的事情（至少对我而言）。我运行rsync复制相同的数据，然后将其删除到名为的NFS挂载中/nfs_mount/TEST。这/nfs_mount/TEST是从托管/导出的nfs_server-eth1。两个网络接口上的MTU均为9000，两者之间的交换机也支持巨型帧。如果可以，rsync -av dir /nfs_mount/TEST/我得到的网络传输速度为X MBps。如果可以，rsync -av dir nfs_server-eth1:/nfs_mount/TEST/我的网络传输速度至少为2X MBps。我的NFS挂载选项是nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp。

底线：两种传输都通过相同的网络子网，相同的线路，相同的接口，读取相同的数据，写入相同的目录等。唯一的区别是通过NFSv3，另一种通过rsync。

客户端是Ubuntu 10.04，服务器是Ubuntu 9.10。

rsync怎么这么快？如何使NFS与该速度匹配？

谢谢

编辑：请注意，我使用rsync写入NFS共享或SSH到NFS服务器并在那里本地写入。我都做过两次rsync -av，从清除目标目录开始。明天我将尝试使用普通副本。

Edit2（其他信息）：文件大小范围为1KB-15MB。文件已经被压缩，我尝试进一步压缩它们，但没有成功。我tar.gz从那做文件dir。这是模式：

• rsync -av dir /nfs_mount/TEST/ =最慢的传输；
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/=启用巨型帧时最快的rsync；没有巨型帧会慢一些，但仍然比直接到NFS的要快得多；
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ =与其非tar.gz等效项相同；

用cp和测试scp：

• cp -r dir /nfs_mount/TEST/=比快一点，rsync -av dir /nfs_mount/TEST/但仍然慢得多rsync -av dir nfs_server-eth1:/nfs_mount/TEST/。
• scp -r dir /nfs_mount/TEST/=整体最快，略有克服rsync -av dir nfs_server-eth1:/nfs_mount/TEST/；
• scp -r dir.tar.gz /nfs_mount/TEST/ =与其非tar.gz等效项相同；

基于此结果的结论：对于此测试，使用tar.gz大文件还是许多小文件都没有显着差异。巨型帧的打开或关闭也几乎没有区别。cp并且scp比它们各自的rsync -av等效物更快。无论使用哪种方法，直接写入导出的NFS共享比通过SSH写入同一目录要慢得多（至少2倍）。

在这种情况下，cp和之间的差异rsync无关紧要。我决定尝试cp并scp只是为了看看他们是否表现出同样的模式，他们这样做- 2倍的差异。

在使用这两种情况rsync或cp两种情况下，我都无法理解是什么导致NFS无法通过SSH达到相同命令的传输速度。

与通过SSH写入同一位置相比，写入NFS共享的速度为何慢2倍？

EDIT3（NFS服务器的/ etc / exports中的选项）rw,no_root_squash,no_subtree_check,sync。客户端的/ proc / mounts显示：nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp。

谢谢你们！

也许不是降低传输速度，而是增加了写入延迟。尝试安装NFS共享异步而不是同步，看看是否能缩小速度差距。当通过ssh进行rsync时，远程rsync进程将异步（快速）写入。但是，当写入同步安装的nfs共享时，不会立即确认写入：NFS服务器等待，直到它们到达磁盘（或更可能是控制器缓存）为止，然后才向NFS客户端发送写入成功的确认。

如果“异步”解决了您的问题，请注意，如果NFS服务器在中间写入时出了点问题，您可能最终会导致磁盘上的数据不一致。只要此NFS挂载不是此（或任何其他）数据的主要存储，就可以了。当然，如果您在rsync-over-ssh运行期间/之后拔掉nfs服务器上的插头（例如，rsync返回已“完成”，nfs服务器崩溃，写缓存中未提交的数据现在会丢失），您将处于同一条船上在磁盘上留下不一致的数据）。

尽管这不是测试的问题（同步新数据），但请注意，通过ssh进行rsync在计算校验和并生成需要处理的文件列表之前，在传输单个字节之前，可能会对远程服务器产生大量CPU和IO需求。更新。

NFS是一种共享协议，而Rsync已针对文件传输进行了优化。当您先验地知道目标是尽可能快地复制文件而不是提供对文件的共享访问权限时，可以进行许多优化。

这应该会有所帮助：http : //en.wikipedia.org/wiki/Rsync

Rsync是一种文件协议，仅在文件之间传输更改的位。NFS是一个远程目录文件协议，它每次都可以处理所有内容……有点像SMB。两者是不同的并且出于不同的目的。您可以使用Rsync在两个NFS共享之间进行传输。

这是有趣的。您可能没有考虑的可能性是您正在传输的文件的内容/类型。

如果您的文件很少（例如，单个文件中的电子邮件），则由于未使用完整的MTU，NFS效率可能会下降（尽管使用TCP over UDP的可能性较小）。

另外，如果您具有高度可压缩的文件/数据，快速的CPU，并且网络没有CPU（*）的速度，则仅通过ssh链接上的隐式压缩即可获得加速。

第三种可能性是文件（或其一个版本）已存在于目的地中。在这种情况下，加快速度是因为rsync协议可以节省您传输文件的时间。

（*）在这种情况下，通过“速度”，我指的是CPU可以压缩数据的速率与网络可以传输数据的速率相比，例如，通过电线发送5MB需要5秒钟，但是CPU可以在1秒内将5MB压缩为1MB。在这种情况下，您的压缩数据传输时间将稍微超过1秒，而未压缩数据为5秒。

我还使用-e“ ssh Ciphers = arcfour”来增加吞吐量。

如果您的目标是将所有文件从一个位置复制到另一个位置，那么tar / netcat将是最快的选择。如果您知道文件中有很多空格（零），请使用-i选项。

消息来源：tar cvif-/ path / to / source | nc DESTINATION PORTNUM目的地：cd / path / to / source && nc -l PORTNUM | 焦油xvif-

如果您知道数据是可压缩的，则对tar命令使用压缩-z -j -Ipixz

我是pixz .. parallel xz的粉丝，它提供了出色的压缩，并且我可以调整网络带宽所需的cpu数量。如果我的带宽较慢，我将使用更高的压缩率，因此我在CPU上的等待时间要多于网络。

消息来源：tar cvif-/ path / to / source | pixz -2 -p12 | nc DESTINATION PORTNUM＃tar，忽略零，使用12个cpu内核的2级pixz压缩DESTINATION：nc -l PORTNUM | 焦油-Ipixz -xvif

如果根据数据集正确调整压缩级别和核心，则应该能够使网络接近饱和并进行足够的压缩，否则瓶颈就变成了磁盘（如果读写磁盘系统位于相同）。

至于rsync，我相信它会像tar使用该选项的方式一样跳过零，因此它传输的数据少于NFS。NFS无法对数据进行假设，因此必须传输每个字节以及NFS协议开销。rsync有一些开销。

netcat基本上没有。.它将发送完整的TCP数据包，其中只包含您关心的数据。

使用netcat和使用scp一样，您必须始终发送所有源数据，不能像使用rsync那样具有选择性，因此它不适合增量备份或类似的事情，但是它对于复制数据或归档非常有用。

您在nfsshare上有文件锁定设置吗？如果禁用该功能，您可能会获得更多性能。

我认为速度的提高至少部分是由于“ rsync src host：/ path”在远程计算机上生成了本地进程以进行发送/接收，从而有效地将您的I / O减少了一半。