web-dev-qa-db-ja.com

dd、cp、rsync、macOS FinderのSMB3ドライブへの書き込み速度に違いがあるのはなぜですか？

Tl; dr – 2つの異なるNASおよびAFPを介してSMBへの書き込み速度が60 MB /秒に制限されている理由がわかりませんMacクライアント。比較：同じネットワーク内の古いWindows 7ラップトップは、安定した100 MB /秒を書き込みます。

この質問を初めて読んだ場合は、更新4セクションに進んでください。理由はわかりませんが、単一ファイルの場合はrsyncが低速の主な理由です。

元の質問：Mac OS 10.11.5以降で速度のボトルネックSMB3/NASを見つける

MacOSのrsync --progress -a /localpath/test.file /nas/test.fileとWindowsのコピー情報を使用してテストしました。

NASは、現在のDSM 6.0.2（5.xでもテスト済み）を実行するDS713 +であり、ギガビットイーサネットコンポーネントのみを備えたRAID1に2つの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. チェック済みS.M.A.R.T.正常に見えます。
  2. さまざまなbsおよびcount設定（128/8、512M/2、1024/1）を使用したdd if=/dev/zero of=write.test bs=256M count=4を使用したディスクへの直接書き込み速度をテストしました。結果：約120 MB /秒（ブロックサイズ/カウントによって異なります）

SMB/AFP

  1. ベンチマークされたSMB2、SMB3、AFPを相互に比較。ほぼ等しい。
    下の更新を参照： macOSのSMB実装を除外するために誤った方法を使用しました。 WindowsではSMBの方が高速です。macOS10.11および10.12に付属する新しいSMB設定が理由である可能性があります。
  2. ソケットオプションを含むSMB設定を微調整しようとした（これに続いて 命令 ）
  3. 遅延ACK設定の異なるバージョンとrsync --sockopts=TCP_NODELAY（コメント）を試した

書き込み速度に大きな変化はありません。設定が実際にロードされていることを再確認し、正しいsmb.confを編集していました。

システム

  1. CPUとRAMの負荷を監視しました。最高のものは何もありません。転送中のCPUは約20％、RAM約25％。
  2. 同じNASをDSM 5.x.xでほぼそのままの設定でテストしました。追加のソフトウェアはインストールされていません。注：これらの2つは異なる場所にあります。 SynologyのCloudSyncを介して同期しています。同じ結果。
  3. システムリソースを消費する可能性のある不要なものをすべて無効にしました。

これはどちらかというとデフォルトの設定であり、派手な改造、クライアント、ネットワークコンポーネントはありません。 Synologyが公開しているメトリックによると、NASは40 MB /秒から75 MB /秒の速度で実行する必要があります。しかし、ボトルネックを見つけることはできません。

クライアント/ NAS

Macクライアントは、MacPro 5,1（標準の有線NIC、10.12.3（16D32）を実行）とMacBookPro10,1（Thunderboltネットワークアダプター、10.11.6を実行）であり、NASから約2mケーブルで、同じ場所で実行されます。テストでは、Windowsラップトップとしてのギガビットスイッチ。

これらのNASの2つは異なる場所にあり、結果は同じです。秒NASは、工場出荷時のデフォルトです（サードパーティのソフトウェアもインストールされていません）。 Synology CloudSyncを介して他のNASと同期する2つのRAID1、EXT4フォーマットのディスク。スイッチを使用せずにNASに直接接続するまで、同じ結果になりました。

重要な更新

MacOS/OS XのSMB実装を除外するために使用された方法は間違っていました。独自のバージョンのSMBを使用することを想定して、仮想マシンを介してテストしましたが、明らかにトラフィックはそのバージョンのSMBを介して実行されているmacOSに渡されます。

Windowsラップトップを使用して、平均100 MB /秒を達成することができました。 10.11および10.12でのSMB実装/更新を示すと、パフォーマンスが低下する可能性があります。 signing_requiredがnoに設定されていても。

誰かがアップデートで変更された可能性があり、パフォーマンスに影響を与える可能性のあるいくつかのさらなる設定を指摘できれば素晴らしいでしょう。

pdate 2 –新しい洞察

AndrewHenle コメントの中で、より詳細な洞察を得るためにWiresharkを使用してトラフィックを詳細に調査する必要があると指摘しました。

したがって、私はNASでSudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpを実行し、2つのテストファイルを512 MBと1 GBで転送しました。そしてWiresharkでダンプを検査しました。

私が見つけたもの：

  1. OSMBとWindowsはどちらもse SMB2のようですが、SMB3はNASで有効になっています（少なくともWiresharkによると）。
  2. OS Xは[〜＃〜] mtu [〜＃〜]に固執しているようです。パケットには1514バイトがあり、さらに多くのネットワークオーバーヘッドと送信されたパケット（ダンプに表示されます）につながります。
  3. Windowsは26334バイトまでのパケットを送信するようです（データを正しく読み取った場合！確認してください）。MTUで許可されていない場合でも、NASでは1500に設定されているため、最大設定です。そこでは9000になります（Synologyもテストで1500設定を使用しています）。
  4. / etc/nsmb.confにsmb_neg=smb3_onlyを追加してmacOSに強制的にSMB3を使用させようとしても、機能しないか、少なくとも高速転送につながらなかった。
  5. TCP遅延ack設定（0〜3）のさまざまな組み合わせでrsync --sockopts=TCP_NODELAYを実行しても効果がありませんでした（注：デフォルトのack設定3でtcpdumpを実行しました）。

.csvファイルとして4つのダンプを作成しました。2つは512 MB（test-2.file）をコピーし、2つは1024 MB（test.file）をコピーしています。 Wiresharkのエクスポートをここからダウンロード （25.2 MB）。それらはスペースを節約するために圧縮され、自明の名前が付けられています。

pdate 3 – smbutil output

コメントで harrymc によって要求された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 /秒、オフにすると60 MB /秒）。

pdate 4 – Samba Wars：A New Hope

やや恥ずかしい感じがしますが、ここでの主な問題は、やはり測定です。

rsync --progress -aの書き込み速度は約30 MB /秒です。 ddを使用してSMB共有に直接書き込み、time cp /local/test.file /NAS/test.fileを使用すると、約85〜90 MB /秒で高速になり、コピーするための最も速い方法はmacOS Finderが約100であることですMB/s（タイミングまたは速度のインジケータがないため、これも測定するのが最も難しい方法です。誰がそれを必要としているのですか？o_O）。ストップウォッチを使用して、最初に1 GBのファイルをコピーし、次に10 GBのファイルをコピーして測定しました。

この質問の最後の更新以降に試みたもの。

  1. MacクライアントからMacクライアントにコピーします。どちらにもSSDがあります（MacProは250 MB/sで自分のディスクに書き込み、MacBook Proは300 MB/sで書き込みます）。結果：MacBook ProからMacProへのdd書き込みによるわずか65 MB /秒（rsync 25 MB /秒）。 25 MB /秒を確認したのは、rsyncの調査を開始した瞬間です。それでも65 MB /秒は非常に遅いです。そのため、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つの（1！）ファイルをコピーするのにそのような高価な方法です。ここで同期/比較することはあまりありませんが、ありますか？ tcpdumpは、オーバーヘッドの可能性も示しません。

  2. SMB共有への転送時に、ddおよびcpがmacOS Finderよりも遅いのはなぜですか？ Finderでコピーすると、TCP通信での確認応答が大幅に少なくなるようです。 （再度：delayed_ack=1などのack設定は、私たちにとって何の違いもありませんでした。）

  3. なぜWindowsはMTUを無視して、送信する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）、ファイル名はコピーされた内容（OS、転送方法、ファイルサイズ）を説明します。

linuxnetworkingperformancenassamba
15
woerndl
  1. 同様の質問ですが、興味深い回答があります。特にコメント5でこのスレッドを確認できます。 https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

ここで「ピーターファンホーフト」を引用します。何を/どのlinux distに基づいてテストするのかよくわかりませんが。そしてrsyncのバージョンも。ただし、1.パフォーマンスを向上できる可能性がある場合は、-sparseフラグを試すように考えます。 2.彼はNFSプロトコルでテストしましたが、同じ速度の問題を満たしました。そのため、ITはプロトコル（SMB2/3、AFPなど）の理由ではない可能性があります。

Rsyncを使用して、1つのファイルサーバーから別のファイルサーバーにデータをコピーしますNFSを使用して、10Gbリンクでマウントします。 バッファサイズ（簡単なテストとして）を上げるとパフォーマンスが向上することがわかりました。 -sparseを使用すると、2MBpsから100MBpsに50倍のパフォーマンスでパフォーマンスが向上します。

  1. 次に、rsyncのパフォーマンスに関する興味深い検査を示します。 https://lwn.net/Articles/400489/

LWN.netには、2010年に投稿された記事であってもパフォーマンスの問題がカーネルに関連する可能性があるという結論があり、NASまたはMacOSでは変更できません。ただし、この記事ではカーネルの問題checksum（私の推測）の計算によって発生する可能性があります。

1つはっきりしている点は、Mythtvシステムのカーネルをアップグレードすることです。一般に、2.6.34および2.6.35-rc3カーネルは、古い2.6.27カーネルよりも優れたパフォーマンスを提供します。しかし、いじくり回しても、rsyncは、100MiB/s以上でコピーする単純なcpに勝ることはできません。実際、rsyncは単純なローカルコピーのために本当に多くのCPUパワーを必要とします。最も高い頻度では、cpは、rsyncの70 + 55秒と比較して、0.34 + 20.95秒のCPU時間しか必要としませんでした。

また、コメントにはこれが含まれています：

Rsync 常に確認転送された各ファイルが、ファイル全体のチェックによって受信側で正しく再構築されたことに注意してくださいchecksumファイルの転送時に生成されます

pdate 1：私の間違い、この説明は--checksumに対するものです。ここで確認してください：[--checksumオプションの説明を改善しました。]PS、3つ以上のリンクを投稿する評判がありません。

しかし、rsyncのmanページから同じ説明が見つからないので、誰かが太字の下で話していると思います：

Rsyncは、サイズまたは最終変更時刻に変更されたファイルを検索する"quick check"アルゴリズム（デフォルト）を使用して転送する必要があるファイルを検出します。ファイルのデータを更新する必要がないことをクイックチェックが示している場合、他の保持されている属性の変更（オプションで要求される）は、宛先ファイルに対して直接行われます。

したがって、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

1
Ou Steven

私が正しく覚えていれば、Rsync/sshはsmbが暗号化しない接続を暗号化します。ファイルが1つしかない場合、一方のシステムはそのファイルを読み取ることができ、もう一方のシステムは読み取れない可能性があります。また、MTUが1514を超えるには、「giants」/「Jumbo Frames」パケットを有効にする必要があることに注意してください。パケットをさらに削減する必要があるという事実は、パケットを「再パック」するオーバーヘッドがあることを意味する場合があります。 2番目に注意する点は、「giants」/「Jumbo Frames」を両端で、またすべての間で有効にする必要があることです。

1514は通常のイーサネットフレームです。 6k-9kフレームは、OS /アプリケーションに応じて、ジャイアントまたは「ジャンボフレーム」と呼ばれます

私のNAS（VMはNASの1つであるVMを備えたPC）とsftp（sshfsを使用）を備えた私のステーション（PC）との間の平均80MB /秒と、中間のデバイスはmicrotik 2011です（truスイッチチップのみ）

MTUは2つのポイント間でネゴシエートされ、パスに沿って異なる容量で複数のMTUが存在する可能性があること、およびMTUが利用可能な最小のサイズになることを覚えておいてください。

編集：SMBは、ファイル転送ではあまり効率的ではありません。

0
Pere Noel