☰

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

tag-icon • tag-icon linux networking performance nas samba
为什么 dd、cp、rsync 和 macOS Finder 对 SMB3 驱动器的写入速度存在差异？

太长不看– 我们无法找到两个不同的 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 测试），带有两个 HGST Deskstar NAS SATA 4TB（HDN724040ALE640），采用 RAID1，仅带有千兆以太网组件和新的以太网电缆（至少为 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设置（128/8、512M/2、1024/1）测试直接写入磁盘的速度count。结果：大约 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配置文件。

系统

  1. 观察了 CPU 和 RAM 负载。没有达到最大值。传输期间 CPU 约占 20%，RAM 约占 25%。
  2. 使用几乎开箱即用的设置测试了同一个 NAS 和 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 仅约 2 米电缆，通过与测试中的 Windows 笔记本电脑相同的千兆交换机运行。

我们在不同位置安装了两台这样的 NAS，结果相同。第二台 NAS 或多或少是出厂默认设置（甚至没有安装第三方软件）。只有两个 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 – 新见解

安德鲁·亨利在评论中指出我应该使用 Wireshark 详细调查流量以获得更多见解。

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

我的发现：

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

我创建了 4 个 .csv 文件转储，其中 2 个是在复制 512 MB（test-2.file）时创建的，另外 2 个是在复制 1024 MB（test.file）时创建的。您可以点击此处下载 Wireshark 导出文件（25.2 MB）。它们被压缩以节省空间，并且名称一目了然。

更新 3 – smbutil 输出

smbutil statshares -a按要求输出哈里麦克在评论中。

==================================================================================================
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 的速度写入）。结果：从ddMacBook 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. 为什么在传输到 SMB 共享时比 macOS Finderdd慢cp？似乎使用 Finder 复制时，TCP 通信中的确认明显较少。（再次说明：例如，ack 设置delayed_ack=1对我们来说没有区别。）

  3. 为什么与 macOS 相比，Windows 似乎忽略了 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

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

这里引用了“Peter van Hooft”的话。虽然我也不确定测试基于哪个 Linux 发行版和 rsync 版本。但是：1. 他给了我们一个尝试的想法- 疏标记是否可能提高性能。2.他在 NFS 协议上进行了测试，但遇到了同样的速度问题，因此，这可能不是协议（SMB2/3、AFP 等）的原因。

我们使用 rsync 将数据从一个文件服务器复制到另一个文件服务器NFS3 通过 10Gb 链路挂载。我们发现，缓冲区大小（作为快速测试）可提高性能。使用- 疏这将性能提高五十倍，从 2MBps 提高到 100MBps。

  1. 这是另一个关于 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选项的描述。]附言：我的声誉不足以发布超过 2 个链接。

但是我在 rsync 手册页中找不到相同的描述，所以我猜有人正在谈论下面的粗体内容：

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

答案2

如果我没记错的话，rsync/ssh 会加密连接，而 smb 不会。如果只有一个文件，那么一个系统可能能够读取该文件，而另一个系统则不能。还要注意，要使 MTU 高于 1514，您需要启用“giants”/“Jumbo Frames”数据包，数据包需要进一步减少这一事实可能意味着“重新打包”数据包会产生开销。第二件需要注意的事情是，两端以及两端之间的所有设备都需要启用“giants”/“Jumbo Frames”。

1514 是正常的以太网帧。6k-9k 帧被称为巨型帧或“巨型帧”，具体取决于操作系统/应用程序

我的 nas（带有虚拟机的 PC，其中一个虚拟机是 NAS）与我的工作站（一台 PC）之间的平均速度为 80MB/s，使用 sftp（使用 sshfs）[未启用 giants]，中间的设备是 microtik 2011（仅通过交换芯片）

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

编辑：SMB 对于文件传输来说效率不高。

相关内容