小さなファイルのバックアップではNVMe SSDがスロットリングするのに、1つの大きなローカルコピーでは発生しないのはなぜですか?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

NVMe SSDは、大容量ファイルを1つコピーする場合とは異なるボトルネックが発生するため、小さなファイルのバックアップ中に速度が低下することがあります。メタデータ、ランダム書き込み、同期バリア、CPU処理などが原因です。

「スロットリング」という言葉は速度低下全般に使われがちですが、熱によるスロットリングは可能性の1つにすぎません。小さなファイルのバックアップでは、ディレクトリエントリの作成、タイムスタンプやアクセス権の更新、ファイルの開閉、チェックサムの計算、データの圧縮や暗号化、メタデータの確定が繰り返し行われます。NVMeの表示速度は低いMB/sでも、1秒あたりの処理件数が増え、レイテンシが高くなっている場合があります。冷却を変更したりドライブを交換したりする前に、同じサイズのローカルワークロードで比較してください。

同じサイズのローカルテストで違いを確認する

合計データ量が同じになるように、大きなファイルを1つ作成し、さらに小さなファイルで構成されたディレクトリツリーを作成します。それぞれを同じNVMeの保存先へローカルコピーし、経過時間、IOPS、レイテンシ、CPU使用率、温度を記録してください。

FioではシーケンシャルI/OモードとランダムI/Oモードを個別に定義できるため、関連性のないバックアップ実行結果を比較するのではなく、ワークロードの特性を切り分けられます。

大きなファイルのローカルコピーは高速なままで、小さなファイルの作成時だけ速度が低下する場合、PCIeリンクとシーケンシャルNANDの経路はおそらく利用可能な状態です。メタデータ、キューのレイテンシ、キャッシュ、CPU、熱を引き続き確認してください。

MB/sだけでなくメタデータ処理を測定する

1秒あたりのファイル数、作成、クローズ、名前変更、ディレクトリ更新、ACL書き込み、拡張属性、同期処理を追跡します。これらをデータ転送速度と比較してください。

Red Hatは、小さなファイルのストレージをメタデータ集約型と説明しています。数千個の小さなファイルでは、NVMeのシーケンシャル帯域幅の上限に達していなくても、MB/sが低くなる理由が分かります。

そのため、バックアップは処理中で正常に動作していても、バイト転送速度が期待外れに見えることがあります。スループットだけでなく、完了したファイル数、レイテンシ、復元要件も基準にしてください。

キャッシュのクリーンアップで書き込みレイテンシが増えるか確認する

空き容量、書き込みバイト数、継続時のレイテンシ、アイドル時間後にパフォーマンスが回復するかどうかを記録します。安全を確認したうえで、トリム直後のテスト領域と通常のバックアップ先を比較してください。

Crucialは、アクティブなガベージコレクションがSSDの速度に影響する可能性があると説明しています。特に、デバイスのアイドル時間や再利用可能な領域が少ない場合に影響が出やすくなります。

小さなランダム書き込みでは、1本のシーケンシャルストリームよりも多くの内部データ移動が必要になることがあります。空き容量に余裕を持たせ、定常状態の小さな書き込みにも公称シーケンシャル速度が適用されると考えないでください。

キューのレイテンシとデバイスの飽和状態を確認する

両方のテスト中に、平均リクエストレイテンシ、キュー深度、使用率、読み書き速度、CPUのI/O待ちを記録します。MB/sが控えめなのにレイテンシが高い状態を探してください。

iostatレポートを使うと、合計スループットがシーケンシャル仕様を大きく下回っていても、多数の小さなリクエストによってデバイスが飽和している状態を確認できます。

バックアップの同時実行数を増やすと、負荷の低いデバイスでは改善する場合がありますが、すでにキューが飽和している場合は悪化することがあります。ワーカー数またはキュー設定は、一度に1つだけ変更してください。

ファイルシステムの記録とファイルデータを分けて考える

送信元と保存先のファイルシステム、およびバックアップで保持されるメタデータを確認します。NTFSでは、MFTの増加量と、セキュリティ記述子、代替データストリーム、タイムスタンプがコピーされるかどうかを記録してください。

Microsoftは、MFTにはファイルごとに少なくとも1つのレコードが含まれると説明しています。これは、合計サイズが同じでも、多数の小さなファイルでは1つのファイルよりはるかに多くのファイルシステム記録処理が発生する理由を示しています。

バックアップでACL、xattr、スパース領域、チェックサムを保持する場合は、それらの処理も比較に含めてください。ベンチマークを改善する目的だけで整合性機能を無効にすると、バックアップの信頼性が低下する可能性があります。

推測ではなく実際の熱によるスロットリングを確認する

NVMeの複合温度、熱警告時間、コントローラーのビジー時間、冷却前後のパフォーマンスを記録します。安定したエアフローと同じ小さなファイル群を使って再テストしてください。

Kingstonは、熱によるスロットリングによってパフォーマンスが低下すると説明しています。SSDが安全な温度に戻るまで性能が抑制されます。

温度のしきい値や熱警告がないままスループットが低下する場合は、熱によるスロットリングではなく、ワークロードのボトルネックと判断してください。冷却では、メタデータ処理の直列化やCPU負荷の高いハッシュ計算は解決できません。

実際に飽和しているバックアップ層を最適化する

チェックサムワーカーを減らす、コピーのワーカーを1つ追加する、メタデータをまとめて処理する、ローカルマニフェストを使用する、再生成可能なキャッシュを除外するなど、適度な変更を1つ試してください。復元に必要なメタデータは保持します。

小さなファイルのSMBコピーのテストに関するZimaSpaceの記事ではネットワークコピーを扱っています。このページでは、大きなファイルのローカルコピーが高速なままの場合に、ローカルNVMeとバックアップパイプラインを切り分けます。

速度低下の原因がメタデータ処理速度、ランダム書き込みレイテンシ、キャッシュのクリーンアップ、CPU処理、または確認済みの熱によるスロットリングのいずれかに対応し、対象を絞った変更によって同じ条件の小さなファイルのテストが改善すれば、診断は完了です。

サポートとヒント

もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Aug 17, 2026

Plexは別のDockerコンテナとGPUを共有できますか?

Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.