複数のサブボリュームを持つBTRFSファイルシステムの重複を削除しようとしています。合計約3.5TBのデータを保持しており、重複排除後はそのサイズが半分以上になると予想されます。私の主な関心事は個々のブロックではなく重複ファイルです（しかし、まだ小さなファイルを重複排除したい）。ファイルサイズは非常に多様です。ドライブは現在メンテナンスモードになっています。これは、重複排除中にファイルが変更されないことを意味します。
duperemove16GBの物理メモリ、8GBのスワップ領域を備えたシステムで動作します。データ量が多く、いつでも中断して再開できるため、ハッシュファイルを使用します。
私の最初の実行はデフォルトのブロックサイズを使用しました。インデックス作成を完了するのに約28日かかりました（21GBのハッシュファイルの生成）。その後、システムはメモリに冗長ハッシュをロードするために8日をさらに消費した後、メモリがほとんど完全に不足して応答しなくなりました。 （duperemoveメモリ使用量はほとんど12〜14 GBの間で変動していますが、システムのどのプロセスでもメモリ使用量が増加したことはわかりませんが、メモリはいっぱいになります。）
追加メモリを追加するオプションは制限されています。私が選ぶ唯一の方法は、USBドライブに追加のスワップスペースを追加することでした。これにより、すでに高価なスワップメカニズムにパフォーマンスの低下が追加されました。それでも不足を防ぐために、この方法で32GBのスワップスペースを追加しました。
しかし、私は別のブロックサイズを試したことがありません（よくある質問にはこれに関する情報はほとんどありません）。基本的に私の質問は次のとおりです。
- メモリ不足を防ぐには、ブロックサイズをどのように選択する必要がありますか？
- 優れた重複排除率を維持しながら最高のパフォーマンスを得るには、ブロックサイズをどのように選択する必要がありますか？ （テストを実行するためにもう1ヶ月待たないのですが、1〜2GBのディスク容量を無駄にする余裕があります。）
- スワッピングによるパフォーマンスの低下は何ですか？スワッピングを必要としないようにメモリ使用量を減らすのに役立ちますか、それともスワッピングしないという利点は他のものと相殺されますか？
- 異なるブロックサイズで作成された既存のハッシュファイルを再利用できますか？それでは、すべてがすでにハッシュされている場合、ブロックサイズを変更すると影響しますか？
ベストアンサー1
完全な答えではありませんが、ブロックサイズについて：テストデータセットで64Kブロックサイズの重複排除がまだ合理的な時間内に完了したことがわかりました。 4Kは小さなシーンには適していますが、大きなシーンには適していません。 300-500Gのデータセットの場合、16Kのブロックサイズはうまく機能しますが、8Kではパフォーマンスが大幅に低下します。
ブロックのサイズを変更する前に、スキャンするデータの量を減らしてください。これがリソースを節約する最良の方法です。
- 複数のスナップショットがある場合（すべて重複排除または読み取り専用）、すべてのスナップショットをスキャンしても利点はありません。 1つだけで十分です。最新であるか、最も長く維持したいのが望ましいです。
- 重複がある場所（たとえば、ほとんど同じパス）のおおよその予想がある場合は、ファイルシステムをより小さな部分に分割して「部分間」重複を最小限に抑え、部分重複によって削除します。多くの反復が予想されないセクションを除外してください。
最後にテストしてみてください。 128K（デフォルト）で始まり、そこで上下に作業します（毎回新しいハッシュファイルを使用）。完了時間がまだ許容可能でメモリが不足していない場合は、より小さいブロックサイズ（半分または1/4）を使用してください。 ）前の記事の内容を繰り返します。あまりにも多くの時間やメモリが必要な場合は中断し、ブロックサイズを2〜4倍に増やします。取ることができる最も低い値は、基本ファイルシステムのブロックサイズですstat -f /path/to/mountpoint（btrfsのデフォルトブロックサイズは4Kです）。
同じデータセットに対して複数の実行を実行している場合：より大きなチャンクがすでに重複排除されているため、2回目以降の実行はより早く完了し、メモリを消費しませんが、ドライブスペースも節約されます。