几天前我注意到一些很奇怪的东西（至less对我来说）。 我运行rsync复制相同的数据，然后删除NFS挂载，调用/nfs_mount/TEST 。 这个/nfs_mount/TEST是从nfs_server-eth1托pipe/导出的。 两个networking接口的MTU都是9000，两者之间的交换机也支持巨型帧。 如果我做rsync -av dir /nfs_mount/TEST/我得到networking传输速度X MBps。 如果我做rsync -av dir nfs_server-eth1:/nfs_mount/TEST/我的networking传输速度至less为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 。
底线：两个传输通过相同的networking子网，相同的线路，相同的接口，读取相同的数据，写入相同的目录等。唯一的区别是通过NFSv3，另一个通过rsync。
客户端是Ubuntu 10.04，服务器Ubuntu 9.10。
rsync如何快得多？ 如何使NFS匹配的速度？
谢谢
编辑：请注意我使用rsync写入到NFS共享或SSH到NFS服务器，并写在那里。 两次我做rsync -av ，从明确的目的地目录开始。 明天我会尝试用简单的副本。
编辑2（附加信息）：文件大小范围从1KB到15MB。 这些文件已经被压缩了，我试图进一步压缩它们，但没有成功。 我从该dir做了tar.gz文件。 这是模式：
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等效; testing与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等效; 结论，基于这个结果：对于这个testing，如果使用tar.gz大文件或许多小文件，则没有显着差异。 巨幅帧的打开或closures也几乎没有区别。 cp和scp比它们各自的rsync -av等价物更快。 无论使用何种方法，直接写入导出的NFS共享比通过SSH写入同一目录的速度要慢很多（至less2倍）。
cp和rsync之间的差异在这种情况下是不相关的。 我决定尝试cp和scp只是为了看看他们是否显示相同的模式，他们做了2倍的差异。
由于我在这两种情况下都使用rsync或cp ，所以我不明白是什么原因阻止了NFS通过SSH达到相同命令的传输速度。
如何写入NFS共享比通过SSH写入同一地点慢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共享asynchronous而不是同步，看看是否closures速度差距。 当通过ssh进行rsync时，远程rsync进程asynchronous（快速）写入。 但是当写入同步安装的nfs共享时，写入不会立即得到确认：NFS服务器在向NFS客户端发送确认写入成功之前等待，直到它们碰到磁盘（或更可能是控制器高速caching）。
如果“asynchronous”修复了您的问题，请注意，如果NFS服务器发生中间错误，您可能会遇到磁盘上数据不一致的情况。 只要这个NFS挂载不是这个（或其他）数据的主存储器，你可能会好起来的。 当然，如果你在rsync-over-ssh运行期间/之后拔掉了nfs服务器上的插头，那么你将会在同一条船上（例如，rsync返回'已完成'，nfs服务器崩溃，写入caching中未提交的数据现在丢失在磁盘上留下不一致的数据）。
虽然不是你的testing（rsyncing新数据）的问题，但请注意rsync over ssh可以在传输单个字节之前在远程服务器上产生显着的CPU和IO需求，同时计算校验和并生成需要的文件列表更新。
NFS是一种共享协议，而Rsync针对文件传输进行了优化; 当您事先知道您的目标是尽可能快地复制文件而不是提供对它们的共享访问时，可以进行很多优化。
这应该有助于： http : //en.wikipedia.org/wiki/Rsync
Rsync是一个文件协议，只传输文件之间的变化位。 NFS是一种远程目录文件协议，每次处理一切…有点像SMB中的某种方式。 这两个是不同的，为了不同的目的。 您可以使用Rsync在两个NFS共享之间进行传输。
这很有趣。 您可能没有考虑到的可能性是您正在传输的文件的内容/types。
如果你有很多小文件（例如单个文件中的电子邮件），NFS效率可能会因为没有使用完整的MTU（可能这不太可能用于TCP over UDP）。
另外，如果你有高度可压缩的文件/数据，快速的CPU和一个没有CPU（*）速度的networking，你可以通过隐式压缩ssh链接来获得加速。
第三种可能性是文件（或其一个版本）已经存在于目的地中。 在这种情况下，加速将是因为rsync协议保存您传输的文件。
（*）在这种情况下，“速度”是指CPU可以压缩数据的速率，与networking可以传输数据的速率相比，例如在线上传输5MB需要5秒钟，而CPU可以在1秒内将5MB压缩成1MB。 在这种情况下，压缩数据的传输时间将稍微超过1秒，而未压缩的数据则是5秒。
我也使用-e“ssh Ciphers = arcfour”来增加吞吐量。
如果你的目标是将所有文件从一个地方复制到另一个地方，那么tar / netcat将是最快的select。 如果你知道你的文件有很多空白（零），那么使用-i选项。
源：tar cvif – / path / to / source | nc DESTINATION PORTNUM DESTINATION：cd / path / to / source && nc -l PORTNUM | 焦油xvif –
如果你知道你的数据是可压缩的，那么在你的tar命令-z -j -Ipixz上使用压缩
我是像pixz的粉丝。parallel xz，它提供了很好的压缩，我可以调整我的networking带宽的CPU的数量。 如果我有更慢的带宽，我会使用更高的压缩率，所以我在cpu上的等待比networking更多..如果我有一个快速的networking，我会使用一个非常低的压缩：
源：tar cvif – / path / to / source | pixz -2 -p12 | nc DESTINATION PORTNUM＃tar，忽略零，使用12个cpu核心的2级pixz压缩DESTINATION：nc -l PORTNUM | tar -Ipixz -xvif
如果你调整压缩级别和核心权利，根据你的数据集，你应该能够保持networking接近饱和，并做足够的压缩瓶颈成为磁盘（通常写入方如果读写磁盘系统是一样）。
至于rsync，我相信它会像tar那样跳过零，所以它传输的数据比NFSless。 NFS不能对数据做出假设，因此必须传输每个字节以及NFS协议开销。 rsync有一些开销..
netcat基本上没有..它会发送完整的TCP数据包，只包含你关心的数据。
对于netcat来说，和scp一样，你必须始终发送所有的源数据，你不能像rsync那样有select性，所以它不适合增量备份或者类似的事情，但是对于复制数据或者存档来说是很好的。
你有nfsshare文件locking设置？ 如果被禁用，你可能会获得更多的性能。
我认为增加的速度至less部分是由于“rsync src host：/ path”在远程机器上产生一个本地进程来发送/接收，有效地减less了一半的I / O。