为什么dd，cp，rsync和macOS Finder对SMB3驱动器的写入速度有差异？

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是运行当前DSM 6.0.2（也已通过5.x测试）的DS713 +，两个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. 检查所有电缆。状况良好，至少一切都很好。

磁碟

1. 已检查SMART看起来很健康。
2. dd if=/dev/zero of=write.test bs=256M count=4使用各种bs和count设置（128 / 8、512M / 2、1024 / 1）直接测试到磁盘的写入速度。结果：大约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笔记本电脑进行了测试。

我们有两个位于不同位置的NASes，结果是相同的。秒NAS或多或少是出厂默认设置（甚至没有安装第三方软件）。仅两个RAID1，EXT4格式的磁盘通过Synology CloudSync同步到另一个NAS。我们进行了尽可能多的直接连接而无需切换的NAS，结果相同。

重要更新

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

现在，使用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，OS X和Windows似乎都使用了SMB2（至少根据Wireshark而言）。
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文件，其中2个在复制512 MB（test-2.file）时创建，另外2个在复制1024 MB（test.file）时。您可以在此处下载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（这也是最难衡量的方法，因为没有时间或速度指示器–谁需要，对吗？我们通过使用秒表先复制1 GB的文件然后复制10 GB的文件来进行测量。

自该问题的上一次更新以来，我们尝试了什么。

1. 从Mac客户端复制到Mac客户端。两者都具有SSD（MacPro以250 MB / s的速度写入自己的光盘，MacBook Pro以300 MB / s的速度写入）。结果：dd从MacBook Pro到MacPro写入仅可达到65 MB / s （rsync25 MB / s）。看到25 MB / s是我们开始质疑rsync的时刻。仍然65 MB / s的速度非常慢。因此，macOS上的SMB实施似乎……很好，值得商question。
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. 与通过macOS进行的所有操作相比，Windows为什么似乎忽略了MTU，发送的MTU大大增加，因此TCP数据包更少，从而获得了最佳性能。

这就是来自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），文件名说明已复制的内容（操作系统，传输方法和文件大小）。

1. 类似的问题，但有有趣的答案，也许您可​​以检查此线程，尤其是在评论5上：https : //bugzilla.samba.org/show_bug.cgi?id=8512#c5

在这里引用“ Peter van Hooft”。虽然我不确定基于什么/哪个linux dist进行测试。和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秒。

还引用评论有这个：

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

更新1：我的错误，此描述适用于--checksum。在这里检查：[改进了--checksum选项的描述。] PS，我没有足够的声誉来发布两个以上的链接。

但是我无法从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

如果我没记错的话，Rsync / ssh不会加密连接smb。如果只是一个文件，则一个系统可能能够读取该文件，而另一个系统则不能。还请注意，要使MTU高于1514，您需要启用“巨型” /“巨型帧”数据包，需要进一步削减数据包的事实可能意味着存在“重新打包”数据包的开销。要注意的第二件事是，两端都需要启用“巨型” /“巨型帧”。

1514是正常的以太网帧。根据操作系统/应用程序，6k-9k帧称为巨型帧或“巨型帧”

我的nas（一台装有VM的PC，其中一台是NAS）和sftp（使用sshfs）的工作站（一台pc）之间的平均速度为80MB / s（未启用巨人），而两者之间的设备是microtik 2011（正在运行）仅限tru开关芯片）

请记住，MTU是在两点之间协商的，沿着一条路径，您可能会以不同的容量拥有多个MTU，并且MTU将是最低的。

编辑：SMB对于文件传输不是很有效。