web-dev-qa-db-ja.com

数百万の小さなファイルのファイルシステム

次のシナリオで最高速度にどのLinuxファイルシステムを選択しますか。

  • 1億ファイル
  • 平均で〜2kのファイルサイズ
  • 95％以上の読み取りアクセス
  • かなりランダムアクセス
  • 高い同時実行性（> 100プロセス）

注：ファイルは、大きなディレクトリを避けるために深い階層ツリーに格納されます。各リーフディレクトリには、約1,000個のファイルが含まれています。

それをどのようにベンチマークしますか？

linuxfilesystemsbenchmark
44
bene

ここにいくつかの すべての主要なLinux FSを比較した結果 を、開始点として使用できるbonnie ++と組み合わせます。

ランダムシークに関しては、Reiserが勝利し、続いてEXT4、JFSが続きます。これがディレクトリルックアップと正確に相関するかどうかはわかりませんが、指標のようです。具体的には、独自のテストを行う必要があります。 EXT2は、おそらくジャーナルがないため、ファイル作成時にパンツをすべて打ち負かしますが、EXT4は、ハンザライザの現在のステータスが原因で使用しない可能性がある、ライザ以外のすべてを打ち負かします。

NCQをサポートするドライブを調べて、インストールがそれを使用するようにセットアップされていることを確認してください。重いシークの下では、速度が向上するはずです。

最後に、マシンに大量のRAMがあることを確認します。ファイルは頻繁に更新されないので、Linuxは、空き容量がある場合、それらのほとんどをRAMにキャッシュすることになります。使用パターンが正しい場合、これにより速度が大幅に向上します。

20
Andrew Cholakian

私は Reiser4 または古い（しかしよりサポートされている） ReiserFS を推奨することを除いて、Andrewの発言のほとんどに同意します。これらのテスト（およびReiserFSのドキュメント）が示すように、それは正確にあなたが求めている状況（多数の小さなファイルまたはディレクトリ）向けに設計されています。私は過去にGentooとUbuntuでReiserFSを問題なく使用しました。

Hans Reiserのステータスについては、ファイルシステム自体のコードまたは安定性に問題があるとは思いません。 Reiser4はDARPAとLinspireの両方からも提供されているので、Reiserファイルシステムの今後の開発は未定であることに同意しますが、誰かがそれを使用するべきかどうかについて決定的な要素となることはありません。

8
Mike

これはあなたの質問に対する直接の回答ではないことは知っていますが、これらの場合、データベースをホストするのにデータベースの方が適していると思います。小さなファイルは、バイナリ形式でデータベーステーブルに保存し、wilで取得できます。これらのファイルを使用しているソフトウェアは、これをサポートできるはずです...

4
Jeroen Landheer

Unix StackExchangeの誰かが、このシナリオだけをテストするためのベンチマーク（ソース付き）を作成しました。

Q：多くの小さなファイル（SSDではなくHDD）を格納するための最も高性能なLinuxファイルシステムは何ですか？

最高の読み取りパフォーマンスは、ReiserFSにあるようです。

3
thenickdude

私の経験では、小さなファイルの場合、ext2はext4を水から吹き飛ばします。書き込みの整合性を気にしない場合、それは素晴らしいことです。たとえば、Subversionはたくさんの小さなファイルを作成し、ext4や他のファイルシステム（XFS）がチョークします（データをext2からext4にrsyncするcronジョブを実行して30分ごとに問題を実質的に解決します）。

これらのコマンドを実行すると、ext2がさらに高速になります（これらのオプションのほとんどは、クラッシュする前に同期を実行しない限り、クラッシュ後にファイルシステムを不安定にします）。これらのコマンドは、小さなファイルの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
3
Jason Hall

私はext3（またはext4）を推測します。おそらくJFSは素晴らしいソリューションでしょう。私はext4とbtrfsには注意が必要です（ファイルシステムは注意が必要です。最新のものを使用する場合は、バックアップを用意してください）。

ファイルシステムを好みに合わせて調整するために、mkfsの時間中に調整できるさまざまなパラメーターもあります。

私は確かにに対して XFSをお勧めします。ファイルシステムが悪いからというわけではありませんが、作成/削除はコストのかかる操作です。

ディレクトリ検索の問題を回避するには、次のようなインテリジェントな命名スキームを使用します。

<first letter of id>_<last letter of id>/<id>

または同様の、より複雑なスキーム。これにより、ディレクトリ検索が高速化され、全体的なアクセス速度が向上します。 （私は思うV7から戻った、古いUNIXトリックです）

1
p_l

ほとんどのFSは、ディレクトリ内の65Kを超えるファイルで窒息しますが、ext4の場合はまだ当てはまります。Reiserファイルシステムにはその制限がありません（mp3.comのユーザーは、他のことについてはわかりませんが、それはReiserFSが作成された使用シナリオの1つです。

1
Ronald Pottol