次のシナリオで最高の速度を得るには、どのLinuxファイルシステムを選択しますか。
- 1億個のファイル
- 平均約2kのファイルサイズ
- > 95%の読み取りアクセス
- かなりランダムなアクセス
- 高い同時実行性(> 100プロセス)
注:ファイルは、大きなディレクトリを避けるために、深い階層ツリーに格納されます。各リーフディレクトリには、約1,000個のファイルが含まれています。
どのようにベンチマークしますか?
次のシナリオで最高の速度を得るには、どのLinuxファイルシステムを選択しますか。
注:ファイルは、大きなディレクトリを避けるために、深い階層ツリーに格納されます。各リーフディレクトリには、約1,000個のファイルが含まれています。
どのようにベンチマークしますか?
回答:
以下は、すべての主要なLinux FSを、出発点として使用できるbonnie ++と比較した結果です。
ランダムシークに関しては、Reiserが勝利し、EXT4、JFSが続きます。これがディレクトリルックアップと正確に相関するかどうかはわかりませんが、それは指標になるようです。具体的には、独自のテストを行う必要があります。おそらくジャーナルがないため、EXT2はファイル作成時間についてはすべてズボンを打ち負かしますが、まだhans reiserの現在のステータスのために使用したくないReiserを除くすべてをEXT4は打ち負かしています。
NCQをサポートするドライブを調べて、それを使用するようにインストールがセットアップされていることを確認したい場合があります。重いシークでは、速度が向上します。
最後に、マシンに大量のRAMがあることを確認してください。ファイルは頻繁に更新されないため、Linuxは空き領域があればほとんどのファイルをRAMにキャッシュします。使用パターンが正しい場合、これにより、速度が大幅に向上します。
アンドリューが言ったことの大部分に同意しますが、Reiser4または古い(ただし、より良いサポートが必要な)ReiserFSをお勧めします。これらのテスト(およびReiserFSのドキュメント)が示すように、それは正確にあなたが尋ねている状況(多数の小さなファイルまたはディレクトリ)のために設計されています。私は過去にGentooとUbuntuで問題なくReiserFSを使用しました。
Hans Reiserのステータスについては、コードまたはファイルシステム自体の安定性に問題があるとは思いません。Reiser4はDARPAとLinspireの両方が後援しているので、Reiser File Systemのさらなる開発は未定であることに同意しますが、だれかがそれを使用するかどうかを決定する要因になるべきではありません。
これはあなたの質問に対する直接的な答えではないことは知っていますが、これらのケースでは、これをホストするのにデータベースの方が適していると思います。小さなファイルは、バイナリ形式でデータベーステーブルに保存し、wilで取得できます。これらのファイルを使用しているソフトウェアは、これをサポートできるはずです...
Unix StackExchangeの誰かが、このシナリオをテストするためのベンチマーク(ソース付き)を作成しました。
Q:多くの小さなファイル(SSDではなくHDD)を保存するための最も高性能なLinuxファイルシステムは何ですか?
最高の読み取りパフォーマンスはReiserFSから得られるようです。
私の経験では、ext2は小さなファイルのために水からext4を吹き飛ばします。書き込みの整合性を気にしないのであれば、それは素晴らしいことです。たとえば、subversionはたくさんのたくさんの小さなファイルを作成し、ext4やその他のファイルシステム(XFS)が停止します(30分ごとにデータをext4からext4にrsyncするcronジョブを実行して、問題を実質的に解決します)。
これらのコマンドを実行すると、ext2はさらに高速になります(これらのオプションのほとんどは、クラッシュする前にsyncを実行しない限り、クラッシュ後にファイルシステムを不安定にしますが)。これらのコマンドは、小さなファイルを含むext4にはほとんど効果がありません。
echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure
ext3(またはext4)、おそらくJFSがいい解決策だと思います。ext4とbtrfsには注意が必要です(ファイルシステムは扱いにくいです-最新の最新のものを使用する場合は、バックアップを用意してください)。
ファイルシステムを好みに合わせて調整するためにmkfsの時間中に微調整できるさまざまなパラメーターもあります。
私は確かにXFS に対してお勧めします。悪いファイルシステムだからではなく、作成/削除はコストのかかる操作です。
ディレクトリ検索の問題を回避するには、次のようなインテリジェントな命名スキームを使用します。
<first letter of id>_<last letter of id>/<id>
または同様の、より複雑なスキーム。これにより、ディレクトリ検索が高速化され、全体的なアクセス速度が向上します。(これは古いUNIXトリックで、V7から戻ってきたと思います)
ほとんどのFSは、ディレクトリ内に65Kを超えるファイルが詰まっています。それはext4にも当てはまります。Reiserファイルシステムにはその制限はありません(mp3.comの人々はそれを確認するために支払いました)。他のことについてはわかりませんが、それはReiserFSが作成された使用シナリオの1つです。
ls
かタブ補完をしない限り、それは速く働きます。おそらくインデックスが原因です。