小文件的NFS传输性能较慢

我在HP ML370 G5，智能阵列P400，使用RAID 1 + 0组合的SAS磁盘上使用Openfiler 2.3。

我使用Openfiler的基于Web的配置从ext3分区设置了NFS共享，然后成功从另一台主机挂载了共享。两个主机都使用专用的千兆链路连接。

使用简单基准dd：

 $ dd if=/dev/zero of=outfile bs=1000 count=2000000
 2000000+0 records in
 2000000+0 records out
 2000000000 bytes (2.0 GB) copied, 34.4737 s, 58.0 MB/s

我看到它可以达到中等的传输速度（58.0 MB / s）。

但是，如果我复制包含许多小文件的目录（.php和.jpg总规模约300 MB的，每个文件围绕1-4 KB），该cp过程结束在10分钟左右。

NFS是否不适合上述情况下的小文件传输？还是有一些必须调整的参数？

有许多原因导致传输许多小文件总是比传输单个大文件要慢。读取时，文件更有可能散落在磁盘周围，因此需要在各处进行搜索以获取它们。正如Evan所提到的，在NFS（或任何其他文件系统！）的情况下，还涉及元数据，这也使事情变得复杂。

您可以尝试将您的rsize和wsize参数增加到NFS挂载，看看是否会对性能有所帮助。另外，请查看有关调整NFS以使延迟最小化的问题，因为它提供了许多有用的建议，这些建议将在许多小文件传输的情况下提供帮助。

我没有很多NFS经验，但是我对其他网络文件共享协议的经验表明，在“许多小文件”情况下，性能几乎普遍受到影响。您正在承受往返延迟，并且在一大堆文件中，延迟加起来了。

您是否尝试过使用其他文件系统，例如XFS？当进行大量的小型iSCSI块传输时，它解决了我所有的问题。不知道为什么。

此外，iSCSI / NFS通常配置为用于相当大的数据帧（巨型帧等），如果一次仅复制一个小文件，则可能会伤害您。也许先去皮，然后转移对您有帮助。

检查您是否正在使用TCP连接（mount -t nfs -o tcp host：/ mount / target）。现代系统上的性能不会受到影响，但是如果您的网络已加载，小型IO可能会大大改善。

您还应该尝试其他文件系统；ext3基本上是最慢的。它是可靠的，众所周知的，但是非常不适合文件服务器。XFS更好，小型IO的reiserfs也更好。

如果要通过NFS传输包含小文件的大型目录树，并且可以登录到服务器，则最好的方法是制作一个在客户端上自动提取的tar文件，如下所示：

tar c mydirectory | ssh user @ host tar -xf--C目标目录

这样，只有一个“文件”会通过网络传输，您将立即将所有文件保存在主机上。

只是为了增加Evan的答案，您还需要为要复制的每个文件创建元数据（目录条目等）的所有开销。

与Chris的答案类似的解决方案是定期将文件同步到客户端。如果要进行双向更改，也可以统一使用。

问题是您的共享带有sync选项（默认）。用于async大大加快写入速度。参见nfs.sourceforge.net/nfs-howto/ar01s05.html