質問: 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のファイルをコピーして測定しました。この質問の最後の更新以降に試みたもの。 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の実装は...まあ、疑問です。 ddとcpを使用してさまざまなack設定を試した-運がない. 最後に、使用可能なすべての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は有効な同等のものである必要があります。とにかく、これらの設定はどれも私たちに違いをもたらしませんでした。一目でわかる新しい質問 なぜrsyncは1つの(1!)ファイルをコピーするのにそのような高価な方法です。ここで同期/比較することはあまりありませんが、ありますか? tcpdumpは、オーバーヘッドの可能性も示しません。 smb共有への転送時に、ddおよびcpがmacos finderよりも遅いのはなぜですか? finderでコピーすると、tcp通信での確認応答が大幅に少なくなるようです。 (再度:delayed_ack=1などのack設定は、私たちにとって何の違いもありませんでした。) なぜ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、転送方法、ファイルサイズ)を説明します。
回答: 同様の質問ですが、興味深い回答があります。特にコメント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倍のパフォーマンスでパフォーマンスが向上します。 次に、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のソースコードを読み取ることができないため、これが最終的な理由であることを確認できません。私の考えはチェックし続けることです: awenroがテストに使用しているrsyncのバージョンは何ですか?最新バージョンに更新できますか? --statsと-vを--debug = flagsと組み合わせて使用したときの出力を見てみましょう 旗 --statsこれは、rsyncにファイル転送に関する詳細な統計のセットを出力するように指示します。これにより、rsyncアルゴリズムがデータに対してどの程度効果的であるかを知ることができます。 --debug = flagsこのオプションを使用すると、表示したいデバッグ出力をきめ細かく制御できます。個々のフラグ名の後にレベル番号を付けることができます。0はその出力を無音にすることを意味し、1はデフォルトの出力レベルです。番号が大きいほど、そのフラグの出力が大きくなります(高いレベルをサポートするものの場合)。 -debug = helpを使用して、使用可能なすべてのフラグ名を確認してください、それらが出力する内容、および詳細レベルが上がるたびに追加されるフラグ名。 最後に、この補足記事を読んで知識を深めることをお勧めします。 "ネットワークを介して大量のデータを転送する方法" moo.nac.uci.edu/~hjm/howto_move_data.html