1回の連続転送で最初の50GBを超えると、USBバックアップの速度が急激に低下するのはなぜですか？
高速キャッシュがいっぱいになったり、持続的な処理によって低速なストレージ、熱、または転送経路の上限が明らかになったりすると、USBバックアップの速度は数十GB後に急激に低下することがあります。
最初の50GBは、普遍的な閾値ではありません。転送がバースト動作から定常状態の動作へ移行した、別のファイルセットに到達した、SSDキャッシュがいっぱいになった、SMRのクリーンアップが始まった、エンクロージャーが発熱した、またはUSBの再試行が発生したことを示す手がかりです。正確な診断には、同じソースデータを使い、大容量ファイルと小容量ファイルで管理されたテストを行いながら、保存先のレイテンシ、温度、リンクエラー、実際の書き込みバイト数を記録して比較します。
速度低下がバイト数、時間、ファイル数のどれに連動するかを確認する
経過時間、転送バイト数、ファイル数、平均ファイルサイズ、ソースの読み取り速度、保存先の書き込み速度、そしてスループットが低下した正確な地点を記録しながら、範囲を限定したバックアップを繰り返します。
Fioはシーケンシャルワークロードとランダムワークロードを区別できるため、保存先の速度低下が一定の書き込みバイト数後に発生するのか、それともバックアップが大量の小容量ファイルに到達したときだけ発生するのかを検証するのに適しています。
ファイル構成にかかわらず、ほぼ同じ書き込みGB数で速度が急落する場合は、キャッシュと熱の上限を調べます。ファイル数やディレクトリの深さに応じて発生する場合は、メタデータ処理とアプリケーションのオーバーヘッドがより疑わしい原因です。
SSDのバーストキャッシュがいっぱいになっていないか確認する
保存先のメディアを特定し、モデル、空き容量、温度、ファームウェア、持続的な書き込み性能を記録します。最初の1分間と、速度低下後の速度を比較してください。
Crucialは、バックグラウンドのガベージコレクションにクリーンアップの時間が必要になるとSSDの性能が低下することを説明しています。そのため、短時間の高速バーストは、ドライブの長時間書き込み速度を示すものではありません。
ドライブが冷却され、バックグラウンドのクリーンアップを実行できる十分な時間を確保するためにワークロードを一時停止し、同じデータで再開します。一時的に速度が回復した場合、キャッシュまたは熱の影響が考えられますが、温度とレイテンシの証拠がなければ、どちらが原因かは特定できません。
ドライブ管理型SMRのクリーンアップを除外する
USBの保存先にドライブ管理型SMRディスクが含まれているか確認します。1本の大容量シーケンシャルストリームと、多数の小容量ファイルを繰り返し更新または作成するバックアップを比較してください。
Seagateは、SMRは予測可能な書き込みで最も高い性能を発揮する一方、断片化された更新やランダム更新では内部で追加のデータ移動が発生し、定常状態の速度が低下する可能性があると説明しています。
容量やブランドだけでSMRだと判断しないでください。正確なモデルを確認し、頻繁な増分バックアップやメタデータ中心のバックアップと特性が合わないドライブの使用は避けます。
USBのリセット、自動サスペンド、リンクの再試行を確認する
バックアップ開始前から速度低下が発生するまでのホストログを保存します。デバイスのリセット、UASエラー、コマンドの中断、ネゴシエーションされた速度の変化、切断、自動サスペンドへの移行を確認してください。
LinuxカーネルのUSBランタイム電源管理に関するドキュメントは、ストレージメディア自体の速度低下と、持続的な負荷の下で繰り返しサスペンド、復帰、リセットを行う転送経路を切り分けるのに役立ちます。
USBリンクが接続されたままでも、再試行によって実効スループットが低下することがあります。ファイルシステムやバックアップ設定を変更する前に、背面の直接接続ポート、動作確認済みの短いケーブル、適切な電源アダプター、別のホストを試してください。
バックアップが小容量ファイルのワークロードに変化していないか確認する
速度低下の前後で、平均ファイルサイズ、ファイル作成速度、メタデータ操作、ACL処理、チェックサム、圧縮、暗号化を比較し、バックアップログを調べます。
Red Hatは、小容量ファイルのストレージをメタデータ中心のワークロードとして説明しています。そのため、バックアップが大容量のデータファイルから、大量の作成、クローズ、stat、ディレクトリ更新へ移行すると、MB/sの値が低下するのは正常な場合があります。
メガバイト毎秒だけでなく、1秒あたりのファイル処理数も測定します。小容量ファイルの処理中はバイトスループットが低くても、ストレージスタックが稼働し、応答性を維持している場合があります。
空き容量、discard、書き込み増幅を確認する
保存先の空き容量、スナップショットの保持、ゴミ箱の使用状況、シンプロビジョニング、そしてUSBブリッジとファイルシステムを通じてdiscardがSSDに到達するかどうかを記録します。
fstrimのマニュアルでは、未使用ブロックを効率的に再利用するには、対応するストレージへその情報を伝える必要があると説明しています。
discardを安全に通過させないエンクロージャーでは、discardを有効にしないでください。まず十分な空き容量を意図的に確保し、対応するクリーンアップ後に同じバックアップ区間を比較します。
ハードウェアを交換する前に、管理されたA/Bバックアップを1回実行する
大容量ファイルのテストセットと、同じ容量の小容量ファイルのテストセットを1つずつ作成します。冷却後、同じ保存先にそれぞれ実行し、その後、温度とエラーを記録しながら別のUSB経路または保存先でも繰り返します。
ZimaSpaceの大規模な初回バックアップの段階的な実行に関するガイドでは、バックアップのスケジュール設定やネットワークの飽和と、保存先の定常状態の性能を切り分けるための関連手法を紹介しています。
速度低下が、キャッシュの枯渇、SMRのクリーンアップ、ファイル構成、発熱、USBの再試行、再利用可能な空き容量の不足のいずれか、測定可能な1つの条件に連動し、修正後の経路で期待される定常状態の速度を維持できれば、診断は完了です。
よくある質問
50GB後に速度が低下した場合、ドライブに50GBのキャッシュがあると証明できますか？
いいえ。閾値は、経過時間、温度、ファイル構成、空き容量の圧迫、内部クリーンアップを反映している場合もあります。キャッシュ容量を推定する前に、異なるデータ構成で繰り返しテストしてください。
バックアップを一時停止すると、なぜ一時的に速度が回復するのですか？
一時停止によって、SSDがキャッシュ済みデータを整理したり、SMRディスクが書き込みを再編成したり、エンクロージャーが冷却されたり、USB転送経路が復旧したりする可能性があります。これらを切り分けるには、温度とレイテンシのログが必要です。
バックアップの性能は初期速度で判断すべきですか？
いいえ。容量計画では、キャッシュがいっぱいになり、データ、メタデータ、検証、保持処理が通常の構成になった後の安定した速度を使用してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
