数千の小さなファイルでSMBコピー速度が低下する場合、最初に何をテストすべきですか？
SMBやネットワーク設定を変更する前に、トリガーがリンク速度ではなくファイル数であるかどうかをテストしてください。
家庭用NASでは、数千の小さなファイルがクライアントとサーバーに対して、パスの検索、権限チェック、オープン、作成、メタデータの更新、クローズ、アプリケーション側のスキャンを各オブジェクトごとに繰り返させます。ギガビットや2.5GbEのリンクはほとんどアイドル状態のままでもコピーは遅々として進まないことがあるため、最初の有効なステップは、総バイト数はほぼ同じに保ちつつオブジェクト数を変えるA/Bテストを行い、その後にストレージ、クライアント、コピー・ツールのテストを決まった順序で実施することです。
同じバイト数の大きなファイルと小さなファイルを比較する
同じソースストレージ上に、1つの大きなファイルと、ほぼ同じ総サイズの数千の小さなファイルを含むフォルダの2つのテストセットを作成します。どちらも同じクライアント、SMBパス、時間帯で同じNAS共有にコピーしてください。
TrueNASユーザーの報告では、小さなファイルのSMB遅延の特徴的なパターンが示されており、大きなファイルはほぼ通常のネットワーク速度を維持しています。この対比は単一の速度数値よりも有用で、ワークロードの形状がボトルネックを変えることを証明しています。
経過時間、総ファイル数、総バイト数、秒あたりファイル数、平均MB/s、遅延がすぐに始まるかキャッシュが満たされた後かを記録してください。両方のセットが遅い場合は、まず一般的なネットワークまたはストレージ経路を調査し、小さなファイルセットだけが遅い場合はメタデータに焦点を当てたテストを続けます。
ネットワーク容量とファイルごとの作業を分離する
同じクライアントとNAS間でメモリ間ネットワークテストを実行し、その結果を大きなファイルのSMB結果と比較します。クリーンなネットワークテストと高速な大きなファイルコピーは、リンクがデータを運べることを示しつつ、小さなファイルのワークロードがリンクを満たせていないことを示します。
小さなファイルはコピーを繰り返しのリクエスト・レスポンス作業に変えます。Eclectic Lightは、SMBのメタデータが多いバックアップが予想外に長時間かかることを記録しています。
この結果に対してMTU、デュプレックス、リンクアグリゲーションを最初に変更しないでください。秒あたりファイル数と負荷時レイテンシを追跡し、繰り返しの作業がソース、NASの宛先、またはクライアント側の検査のどこで待機しているかを次に調べることが有効です。
ソースと宛先のメタデータレイテンシを別々にテストする
小さなファイルセットをソースからクライアントの別のローカルフォルダにコピーし、同じセットをNAS上でローカルに作成または展開します。これら2つのテストは、SMBを介さずにソースの読み取りとNASの作成を分離します。
Unraidのディスカッションでは、大きなファイル転送時には見られなかったファイルごとの遅延が測定されました。重要なポイントは、ネットワークが関与する前にローカルの宛先作成がすでに遅いかどうかです。
クライアントローカルコピーが遅い場合は、ソースのディスク、ファイルシステム、暗号化、ファイル配置を調査してください。NASローカル作成が遅い場合は、宛先プール、キャッシュ層、パリティパス、空き容量の断片化、メタデバイス、同期書き込み動作を調査し、SMBの調整を行う前に確認してください。
両端でのセキュリティスキャンとインデックス作成を測定する
アンチウイルス、エンドポイント保護、サムネイル生成、コンテンツインデックス、同期監視、メディアスキャナーは新しいファイルごとに検査を行うことがあります。これらの固定のオブジェクトごとのコストは、数千のアイテムを迅速に作成するワークロードで支配的になることがあります。
専用のテストフォルダだけでリアルタイムスキャンとインデックス作成を一時的に除外した制御テストを1回実行し、すぐに保護を復元してください。目的はセキュリティを無効にしたままにすることではなく、遅延がファイルごとの検査に起因するかどうかを判断することです。
秒あたりファイル数が急増した場合は、信頼できるバックアップのステージングや生成されたキャッシュデータのみに安全な長期除外を作成するか、転送後にスキャンをスケジュールしてください。結果が変わらなければ元の設定を復元し、説明のつかない例外を積み重ねるよりもコピー・ツールの挙動に移行してください。
データセットを変えずにコピー・ツールと同時実行性を比較する
File Explorer、Finder、Robocopy、rsync、バックアップクライアント、アーカイブツールは、キュー深度、メタデータ呼び出し、リトライルール、並列処理が異なります。無関係なワークロードを比較するのではなく、同じソースツリーと宛先で2つのツールを比較してください。
Resilioの大量ファイル数のスキャンに関する議論は、内容の変化が少なくてもジョブがメタデータに縛られ続ける理由を示しています。スレッド数を増やすとレイテンシの一部を隠せますが、同時作成でNASを過負荷にすることもあります。
同時実行数を一段階ずつ増やし、秒あたりファイル数が改善しなくなったり、レイテンシが急増したり、NASが書き込みをキューイングし始めたら停止してください。ツールが許す最大値ではなく、実際のワークロードで一貫して改善する設定を維持してください。
結果のパターンを使って最小限の修正を選ぶ
診断は、ネットワーク容量、ソース読み取り、NAS作成、エンドポイントスキャン、SMBリクエストの挙動、コピー・ツールのいずれかの支配的な段階を指し示すはずです。すべての可能な調整を1つの実験にまとめないでください。最終的な速度変化が原因を説明できなくなります。
ZimaSpaceのファイル数がNASの作業を増やす仕組みは、このワークロードでMB/sよりも秒あたりファイル数が重要になる根本的な理由を提供します。
同じ小さなファイルセットが繰り返しの実行で改善し、大きなファイルの速度、権限、復元動作、NASの応答性を損なわない場合にのみ修正を受け入れてください。個別のリカバリーが不要な場合は、不変の小さなファイルをアーカイブにまとめてオブジェクトのオーバーヘッドを減らすこともできますが、それはワークフローの判断であり、普遍的なSMB修正ではありません。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
