web-dev-qa-db-ja.com

フォルダ内の数十万ファイルのテラバイトのコピーが遅い

私は現在FreeNASを実行しており、WindowsマシンでSMB 3を使用して、それぞれ約35MBの80000+ファイルを含むフォルダーをコピーします。ここに設定があります

FreeNAS

  • ボンディングされた2x40Gbps接続
  • 接続SMB共有SMB 3.1有効
  • 512 GBのRAMを搭載した1つのXeon 8コア
  • より多くのiopsのために4TBドライブを使用する400TBのストレージRAID Z1
  • RAIDグループごとに5ドライブの23グループ
  • 3x LSI 3008 SAS 3.0 12Gb/sホストバスアダプタ
  • 同様の構成は、SUPERTORAGE SERVER 6048R-E1CR72Lをベースとして使用してthinkmate.comで作成し、拡張シャーシを追加できます。
  • ジャンボフレームを有効にしました
  • 転送中のCPU使用率は約50％です
  • 転送中RAM使用率は60％です

ワークステーション

  • ウィンドウズ10プロ
  • i7 3.6Ghzおよび16GBのRAM
  • 512GB m.2ドライブ
  • PCI 3.0 16xスロットの40Gbpsカード
  • ジャンボフレームが有効
  • TCPオフロードが無効
  • 外部RAID 0（3または4ディスク）ドライブはUSB-C経由で接続されます
  • 転送中のCPU使用率は20％です
  • 転送中のRAM使用率は15％です

したがって、これらのRAID 0ドライブにはそれぞれ約4TBのファイルがあり、各ファイルは35MBです。各フォルダには約80000個のファイルがあります。 8つのワークステーションにわたる8つの同時転送。

Robocopyを使用してファイルをコピーする場合。転送速度は約1.8Gbpsです。その後時間が経過し、コピーがファイルに深くなっていくと、速度は約600Mbpsに低下します。これは、ロボコピーで/ MT：1の/ MT：10を使用しているかどうかに関係なく発生します。 EMCopyのフェアリングはそれほど良くなく、freefilesyncは約3時間後に終了したいと考えています。常に低下するのではなく、少なくとも1.8 Gbpsで安定していることを望みます。これらの転送中にワークステーション上の共有を参照することも応答しなくなります。他の誰かがこれを経験しましたか？

sambazfsfreenasfile-transferrobocopy
6
cohortq

問題は解決されたようです。これが解決策です。

の中に /etc/samba/smb-shares.conf.local

この行は、使用している共有に追加されました

case sensitive = yes

現在、安定した200MBpsで転送しています。理想的な速度ではありませんが、時間の経過とともに速度が低下するわけではありません。これにより、速度低下の問題が修正されます。

1
cohortq

転送速度が遅い原因は、ワークステーションのM2ドライブが大量のランダム読み取りを実行する必要があるということです。

高速NVMe M2（おそらく使用している可能性が高い）は、最大数GB /秒のr/w速度でアドバタイズされます。これは大きなファイルのシーケンシャルリードにも当てはまりますが、状況によってはランダムリードが発生します。一般的なコンシューマー/プロシューマーNVMe M2 SSDのランダム読み取り速度は70MB/sから110MB/sの範囲で、600Mbpsの範囲内です。 SSDのレビューには、ランダムな読み取り速度の結果が含まれていることがよくあります。

Intel Optane SSDなどのSSDがあり、およそ500MB/sの球場でランダムな読み取り速度を提供できます。

さらに、USB-C経由でドライブを接続すると述べています。使用しているテクノロジー（USB3.0、3.1、3.2、Thunderbolt）によっては、この接続によっても速度が低下する可能性があります。内部NVMe M2ドライブ（または他のより高速なPCI-eベースのドライブ）が問題を解決する場合があります。

私の仮定を証明または無効にするために、Windows 10タスクマネージャーまたはパフォーマンスモニターを使用できます。タスクマネージャーは、ドライブがビジー状態である割合を示します。問題のドライブが100％または80％を超える場合、速度を制限している可能性があります。一方、アイドリングの場合は制限ではありません。免責事項：特に外部ドライブではなく、Windowsタスクマネージャーのビジー率がどの程度信頼できるかわかりません。

ソース側のドライブがまったくビジーでないことが判明した場合は、宛先側を確認し、ドライブがそこでどのように動作しているかを確認することができます（iostatツールを使用できます）。

問題の根本的な原因としてソース側と宛先側の両方のドライブを除外できたためにこれで解決しない場合は、基本的なトラブルシューティング手順から始めることをお勧めします。たとえば、大きなファイルを転送して、この転送に同じ制限があるかどうかを確認できます。転送方向を逆にして、小さなファイルの一部をワークステーションにコピーして戻すことができます。反転だけで速度が大幅に向上する場合は、読み取り時のみに制限し、書き込み時ではない、またはその逆に制限するコンポーネントがある可能性があります。

または、間にスイッチを追加せずに直接デバイスを接続することで、一部のコンポーネントを除外するか、テストのためにシナリオから削除できるものをすべて除外します。

5
Jules

bothのソースと宛先の両方で詳細なプロファイリングを行わないと、明確な答えを出すことは困難です。そうは言っても、ソースのNVMeドライブがボトルネックになっているとは思いません。結局のところ、かなりの量または順次読み取りを伴う、非常に大きなファイルを読み取っています。

関連するファイルの数が多いため、NTFSやSMBプロトコル自体の非効率性に傾倒しています。

次のことを試してみることをお勧めします。

  • 宛先ホストで、同期、チェックサム、圧縮を無効にした専用データセットを作成します（例：zfs set sync=disabled <dataset>など）。注：これはテストおよび/または一時的なソリューションとしてのみ検討する必要があります。私はnotこれらの設定をオフにして永続的に実行することをお勧めします。

  • ソースホストで、Linuxライブcd/usbを使用して起動し、（SMBではなく）NFSプロトコルを使用してファイルを転送します。基本的に次のことを行う必要があります。

    • ライブCDで起動します。
    • nfsおよびntfs-3gユーティリティをインストールします。
    • nTFSファイルシステムをマウントします（つまり、/mnt/localdir内）。
    • 宛先でNFSエクスポートを構成します。
    • ソースホストにマウントします（例：mount x.x.x.x:/dstdir /mnt/localdir）;
    • これらのファイルを転送するには、cpまたはrsyncを使用します。
    • 別の端末で、dstat -d -f -nをbothホストで実行して、ファイル転送を監視します。
1
shodanshok