大きなMaildirのrsync / tarを高速化するには？
Rsyncで新しいマシン（100BASE-T以上）にコピーしている非常に大きなMaildirがあります。進行が遅い。非常に遅い。 1 MB /秒のように遅い。これは、ブロックがディスク上のどこに格納されているかに関して本質的にランダムな順序で読み取られている大量の小さなファイルであり、大量のシークストームを引き起こしているためだと思います。ディレクトリをtarしようとすると、同様の結果が得られます。 rsync/tarをディスクブロックの順序で読み取る方法、またはこの問題を克服する方法はありますか？
編集：tar cf/dev/zero Maildir /を試してみましたが、古いシステムでは30分かかりました！ rsyncが最終的に終了した新しいシステムでは、同じテストに18分かかりました。古いシステムで同じディレクトリをダンプするのに8分かかり、新しいシステムでは、dump -0f/dev/zero -b 1024/home/psusi/Maildir /がわずか30秒で完了しました。
最終的に、ディレクトリ名とiノード、iノードとデータブロック、およびディレクトリ名とデータブロックの相関関係を計算する小さなpythonスクリプトを作成しました。 ext4は、ディレクトリ内のファイル名の表示順序とディスク上の保存場所との相関関係がかなり低い傾向があることがわかりました。 ext4メーリングリストで議論した後、これは大きなディレクトリでの検索を高速化するために使用されるハッシュディレクトリインデックスの結果であることがわかりました。名前はハッシュ順に保存されます。これにより、他の名前に比べて順序が効果的にスクランブルされます。
これは修正すべきfsの欠陥であるように思えます。 Ted Ts'o（extメンテナー）は、fsで行うのは難しすぎると感じており、優れたツール（rsyncやtarなど）には、ファイルを読み取る前にiノード番号でディレクトリをソートするオプションが必要です。
そのため、機能強化のリクエストはrsyncとtarに提出する必要があるようです。
考慮すべきいくつかの点：
何個のファイルについて話していますか？
find /path/to/your/maildir/ | wc -lは、大まかな目安を提供します。数十万人でも大丈夫です。数億人は、プルーン、アーカイブ、および一般的にクリーンアップする必要があることを示唆する場合があります。ディスクは遅いですか？包括的
bonnie++から迅速でシンプルなディスクユーティリティベンチマークまで、利用可能な多くのベンチマークがあります。実行して、あなたが苦しんでいるかどうかを確認します。- それはハードウェアの問題を引き起こす可能性があります-より速いものに交換してください
- ファイルシステムの問題-高ランダム読み取りIOPSで非常に遅いことが知られているものを使用していますか？
しかし、最終的にはtarringを転送してからshouldを転送すると、tarを生成したら転送を設定するためにそこにいる必要がありますが、全体のスループットは最高になります。
Atime追跡を無効にするか、新しいディスクパーティションで相対atimeを使用して設定してみてください。これによりオーバーヘッドが制限されます。 ext2のような非ジャーナリングファイルシステムからext3やext4のようなジャーナリングファイルシステムに変更すると、パフォーマンスが低下します。
Maildirsを移動したとき、事前にすべてのディレクトリを適切な場所に取得するための準備rsyncを行いました。その後、実行する更新のみがありました。
実際に移動する準備ができたら、ディレクトリが安定していることを確認することができます。
- sMTPデーモンをキューオンリーモードにします。
- sMTPデーモンによるキューの実行を無効にします。
- ユーザーによるアクセスを無効にします。
ファイルの移動が完了したら、再アクティブ化します。
編集：問題を特定したと思います。 Tarとrsyncは両方ともディレクトリをウォークします。 Maildirの通常のファイル変更により、各ディレクトリのファイルはディスク全体に散らばってしまいます。 dumpのようなツールはパーティションをブロック順に読み取りますが、問題を新しいパーティションに複製します。 2番目のrsyncは、2番目のrsyncよりもはるかに高速に実行されるはずです。