为什么 dd、cp、rsync 和 macOS Finder 写入 SMB3 驱动器的速度存在差异？

Question

Tl; dr – 我们无法找到两个不同 Mac 客户端通过 SMB 和 AFP 写入 NAS 的速度限制为 60 MB/秒的原因。相比之下：同一网络中的旧 Windows 7 笔记本电脑写入稳定 100 MB/秒。

如果您是第一次阅读此问题，请跳至更新 4部分。rsync是低速的主要原因，即使我们不明白为什么（对于单个文件！）。

---

原始问题：使用 Mac OS 10.11.5 及更高版本查找速度瓶颈 SMB3/NAS

我们rsync --progress -a /localpath/test.file /nas/test.file在 macOS 和 Windows 的副本信息上进行了测试。

NAS 是 DS713+，运行他们当前的 DSM 6.0.2（也用 5.x 测试），在 RAID1 中有两个 HGST Deskstar NAS SATA 4TB (HDN724040ALE640)，只有千兆以太网组件和新的以太网电缆（至少 Cat5e）。

Mac 客户端最初的速度仅为 20 MB/秒。但是应用此signing_required=no修复程序（此处描述）通过 SMB2 和 SMB3 将写入速度提高到 60 MB/秒。AFP 还提供大约 60 MB/秒的速度。根据协议和 (Mac) 客户端，结果大约为 5 MB/秒。

我们已经尝试过的：

网络

1. 通过 iperf3 测试网络性能。结果：926 Mbit/s。看起来挺好的。
2. 尝试过双链路聚合/绑定网络接口。没变。
3. 将 MTU 增加到 6000 和 9000。没有变化。
4. 检查了所有电缆。一切都很好，至少 Cat5e，状况良好。

磁盘

1. 检查 SMART 看起来很健康。
2. 直接测试写入速度到磁盘dd if=/dev/zero of=write.test bs=256M count=4与各种bs和count设置（8分之128，512M / 2，1分之1024）。结果：大约 120 MB/s（取决于块大小/计数）

中小企业/法新社

1. 对 SMB2、SMB3 和 AFP 进行基准测试。差不多。
   请参阅下面的更新：使用错误的方法排除了 macOS 的 SMB 实现。Windows 上的 SMB 速度更快，可能是 macOS 10.11 和 10.12 附带的新 SMB 设置的原因。
2. 尝试调整 SMB 设置，包括套接字选项（遵循此说明）
3. 尝试了不同版本的延迟确认设置和rsync --sockopts=TCP_NODELAY（评论）

写入速度无明显变化。我们仔细检查了配置是否真的加载了，我们正在编辑正确的smb.conf。

系统

1. 观察 CPU 和 RAM 负载。没有什么是最大的。传输期间 CPU 约 20%，RAM 约 25%。
2. 在几乎开箱即用的设置中使用 DSM 5.xx 测试了相同的 NAS。没有安装额外的软件。注意：我们在不同的位置有两个。它们通过 Synology 的 CloudSync 同步。结果一样。
3. 停用所有不必要的可能会占用系统资源的东西。

我们认为这是一个相当默认的设置，没有花哨的改编、客户端或网络组件。根据 Synology 发布的指标，NAS 的执行速度应提高 40 MB/s 至 75 MB/s。但是我们就是找不到瓶颈。

客户端/NAS

Mac 客户端是 MacPro 5,1（标准有线 NIC，运行 10.12.3 (16D32)）和 MacBookPro10,1（Thunderbolt 网络适配器，运行 10.11.6）距离 NAS 仅约 2m 电缆，运行在相同的千兆交换机作为测试中的Windows笔记本电脑。

我们在不同的位置有两个这样的 NAS，结果是相同的。秒 NAS 或多或少是出厂默认设置（甚至没有安装 3rd 方软件）。只需两个 RAID1、EXT4 格式的磁盘即可通过 Synology CloudSync 同步到另一个 NAS。我们已经在没有交换机的情况下直接连接到 NAS，结果相同。

重要更新

用于排除 macOS/OS X SMB 实现的方法是错误的。我通过虚拟机对其进行了测试，假设它会使用自己的 SMB 版本，但显然流量会传递给 macOS，通过其 SMB 版本运行。

使用 Windows 笔记本电脑，我现在能够达到 100 MB/s 的平均速度。指示 10.11 和 10.12 附带的 SMB 实现/更新可能会导致性能不佳。即使signing_required设置为no.

如果有人能指出一些可能随着更新而改变并可能影响性能的进一步设置，那就太好了。

更新 2 – 新见解

AndrewHenle在评论中指出，我应该使用 Wireshark 详细调查流量以获得更多见解。

因此sudo tcpdump -i eth0 -s 65535 -w tcpdump.dump，我在 NAS 上运行，同时传输两个测试文件，一个是 512 MB，另一个是 1 GB。并使用 Wireshark 检查了转储。

我发现了什么：

1. 尽管 NAS 上启用了 SMB3（至少根据 Wireshark 的说法），但OS X 和 Windows 似乎都使用 SMB2。
2. OS X 似乎坚持使用MTU。数据包有 1514 字节，导致更多的网络开销和发送的数据包（在转储中可见）。
3. Windows 似乎发送最多 26334 字节的数据包（如果我正确读取了数据！请验证。）即使 MTU 不允许这样做，因为它在 NAS 上设置为 1500，那里的最大设置为 9000（Synology 也是在他们的测试中使用 1500 设置）。
4. 试图通过添加smb_neg=smb3_only到/etc/nsmb.conf来强制 macOS 使用SMB3不起作用，或者至少没有导致更快的传输。
5. rsync --sockopts=TCP_NODELAY使用 TCP 延迟 ack 设置（0 到 3）的各种组合运行没有效果（注意：我使用默认的 ack 设置 3 运行 tcpdump）。

我创建了 4 个转储作为 .csv 文件，在复制 512 MB (test-2.file) 时创建了 2 个，在复制 1024 MB (test.file) 时创建了 2 个。您可以在此处下载 Wireshark 导出(25.2 MB)。它们被压缩以节省空间，并且命名不言自明。

更新 3 – smbutil 输出

smbutil statshares -a根据harrymc在评论中的要求输出。

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
home
                              SERVER_NAME                   server-name._smb._tcp.local
                              USER_ID                       502
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.0
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              QUERYINFO_NOT_SUPPORTED       TRUE
                              DFS_SUPPORTED                 TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------

请注意：我确定SIGNING_SUPPORTED在true这里并不意味着配置中的设置不起作用。但只有NAS支持它。我已经三次检查更改signing_required我的配置中的设置对写入速度有影响（打开时约为 20 MB/s，关闭时约为 60 MB/s）。

更新 4 – 桑巴之战：新希望

感觉有点尴尬，但这里的主要问题 - 再次 - 似乎是测量。

结果表明rsync --progress -a，写入速度的成本约为 30 MB/s。dd直接写入SMB 共享并使用time cp /local/test.file /NAS/test.file速度更快，约为 85-90 MB/s，显然最快的复制方式是 macOS Finder，约为 100 MB/s（这也是最难测量的方法，因为没有计时或速度指示器——谁需要那个，对吧？o_O）。我们通过先复制 1 GB 文件，然后使用秒表复制 10 GB 文件来测量它。

自上次更新此问题以来我们所做的尝试。

1. 从 Mac 客户端复制到 Mac 客户端。两者都有 SSD（MacPro 以 250 MB/s 的速度写入自己的光盘，MacBook Pro 以 300 MB/s 的速度写入）。结果：通过dd从 MacBook Pro 写入 MacPro ( rsync25 MB/s) 的速度仅为65 MB/s 。看到 25 MB/s 是我们开始质疑 rsync 的时刻。65 MB/s 仍然非常慢。所以 macOS 上的 SMB 实现似乎......好吧，有问题。
2. 用 dd 和 cp 尝试了不同的 ack 设置——不走运。
3. 最后我们找到了一种列出所有可用 nsmb.conf 选项的方法。这是一个简单的man nsmb.conf. 注意网络版本已过时！

所以我们尝试了更多的设置，其中包括：

notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes

注意：smb_neg=smb3_only是 - 正如我已经预料到的 - 不是一个有效的设置。protocol_vers_map=4应该是有效的等价物。

无论如何，这些设置都没有对我们产生影响。

新问题一目了然

1. 为什么 rsync 是一种复制一个（1！）文件的昂贵方式。这里没有太多要同步/比较的内容，是吗？tcpdump 也不表示可能的开销。

2. 为什么dd并cp转移到SMB共享时相比，MacOS的慢取景器？使用 Finder 进行复制时，TCP 通信中的确认似乎明显减少。（再次：ack 设置delayed_ack=1对我们没有影响。）

3. 为什么 Windows 似乎忽略了 MTU，发送的 TCP 数据包要大得多，因此 TCP 数据包更少，与通过 macOS 实现的一切相比，性能最佳。

这是来自 macOS 的数据包的样子（始终为 1514）

"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445  >  56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"

这来自 Windows（最多 26334，大小不一）

"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445  >  49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"

您可以在此处下载完整的 .csv (25.2 MB)，文件名说明了复制的内容（操作系统、传输方法和文件大小）。

Answer 1

1. 类似的问题，但有有趣的答案，也许你可以检查这个线程，特别是评论5：https://bugzilla.samba.org/show_bug.cgi ?id=8512#c5

这里引用“Peter van Hooft”。虽然我不确定测试基于什么/哪个 Linux 发行版。还有 rsync 的版本。然而： 1.他给了我们一个想法，如果可能的话，可以尝试使用--sparse标志来提高性能。2. 他在 NFS 协议上进行了测试，但遇到了相同的速度问题，因此，IT 可能不是协议（SMB2/3、AFP 等）原因。

我们使用 rsync通过 10Gb 链接通过NFS3安装将数据从一台文件服务器复制到另一台文件服务器。我们发现增加缓冲区大小（作为快速测试）可以提高性能。当使用--sparse时，性能提高了 50 倍，从 2MBps 到 100MBps。

2. 这是关于 rsync 性能的另一个有趣的检查。 https://lwn.net/Articles/400489/

LWN.net 有一个结论，即性能问题可能与内核有关，即使是 2010 年发布的文章，我们也无法在 NAS 或 MacOS 上进行更改。然而，这篇文章给我们一个想法，内核问题可能是由校验和（我的猜测）计算引起的。

有一点是明确的：我应该升级 Mythtv 系统上的内核。一般来说，2.6.34 和 2.6.35-rc3 内核比旧的 2.6.27 内核具有更好的性能。但是，无论是否进行修改，rsync 仍然无法击败复制速度超过 100MiB/s 的简单 cp。事实上，rsync 确实需要大量的 CPU 能力来进行简单的本地复制。在最高频率下，cp只需要0.34+20.95秒的CPU时间，而rsync需要70+55秒的CPU时间。

还引用评论有这样的：

请注意，rsync始终通过检查文件传输时生成的整个文件 校验和来验证每个传输的文件是否在接收端正确重建

更新1：我的错误，这个描述是针对--checksum的。在这里检查：[改进了 --checksum 选项的描述。] PS，我没有足够的声誉来发布超过 2 个链接。

但我无法从 rsync 手册页找到相同的描述，所以我猜测有人正在谈论下面的 Bold ：

Rsync 使用“快速检查”算法（默认情况下）查找需要传输的文件，该算法查找大小或上次修改时间已更改的文件。当快速检查表明文件的数据不需要更新时，将直接在目标文件上对其他保留的属性（根据选项的请求）进行任何更改。

因此，与 cp/tar/cat 相比，如果我们使用 rsync 复制一堆小文件或大文件，可能会导致性能问题。但由于我无法读取 rsync 的源代码，因此我无法确认这是最终原因。

我的想法是继续检查：

1. awenro 使用什么 rsync 版本进行测试？可以更新到最新版本吗？
2. 让我们看看使用 --stats 和 -v 以及 --debug=FLAGS 时的输出

旗帜

--stats 这告诉 rsync 打印一组有关文件传输的详细统计信息，让您了解 rsync 算法对数据的有效性。

--debug=FLAGS 此选项可让您对想要查看的调试输出进行细粒度控制。单个标志名称后面可以跟一个级别编号，0 表示使输出静音，1 表示默认输出级别，较高的数字会增加该标志的输出（对于那些支持更高级别的级别）。使用 --debug=help 查看所有可用的标志名称、它们输出的内容以及为详细级别的每次增加添加的标志名称。

最后，我建议阅读这篇补充文章以获取更多知识。
《如何通过网络传输大量数据》 moo.nac.uci.edu/~hjm/HOWTO_move_data.html