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


44

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

  • 1億個のファイル
  • 平均約2kのファイルサイズ
  • > 95%の読み取りアクセス
  • かなりランダムなアクセス
  • 高い同時実行性(> 100プロセス)

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

どのようにベンチマークしますか?


3
いくつかの追加情報が必要です。たとえば、すべてのファイルをフラットディレクトリに保存していますか、それともネスト(ソート)ディレクトリに保存していますか?これは、ファイルアクセス時間に劇的なパフォーマンスの影響を与える可能性があります。「フラット」な配置で1億個のエントリを選別すると、FSタイプに関係なく大きなオーバーヘッドが発生します。最良の場合は、何らかの種類のツリー検索を表示していますが、ファイルに到達するには複数の検索が必要です。ファイルをサブディレクトリに分類すると、各レベルで検索するエントリが少なくなるため、アクセス時間が大幅に短縮されます。
エイブリーペイン

ファイルはシリアルまたは同時にアクセスされますか?
スティーブシュネップ2009年

回答:


19

以下は、すべての主要なLinux FSを、出発点として使用できるbonnie ++と比較した結果です。

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

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

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


1
bonnie ++の問題は、私の使用シナリオを大まかにテストすることすらできないことです
bene

2
ディレクトリルックアップをテストしないという点はありますが、正直なところ、それが問題であれば、データを実際のデータベースにダンプする方が良いでしょう。ファイルシステムは、ほとんどのデータベースが使用するように設計されている小さなオブジェクトではほとんど機能しません
Andrew Cholakian 09年

7
@AndrewCholakianリンクは現在無効です。
ドンスコット

8

アンドリューが言ったことの大部分に同意しますが、Reiser4または古い(ただし、より良いサポートが必要な)ReiserFSをお勧めします。これらのテスト(およびReiserFSのドキュメント)が示すように、それは正確にあなたが尋ねている状況(多数の小さなファイルまたはディレクトリ)のために設計されています。私は過去にGentooとUbuntuで問題なくReiserFSを使用しました。

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


3
私は長い間ReiserFSを使用しています。実際、私はまだ再インストールに取り掛かっていない古いGentooサーバーでそれを使用しています。このインストールは今年5月で4年です。私あなたに言えることは、それが著しく減速したということです。この現象は、ReiserFSを使用するすべてのファイルシステムで時間の経過とともに発生します。ReiserFSは、そのようなファイルシステムを備えたすべてのマシンで例外なく読み取り/書き込み使用中です。したがって、長期間にわたって使用する場合念頭に置いて。私はそこから離れ、大きなファイルシステムにXFSを使用しています。
ミハイリンバシャン2009年

3

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


1
階層データベースだけでなく、ファイルシステムとは何ですか?あなたの提案は、おそらく保証されない抽象化、複雑さ、およびソフトウェアの層を追加します。さらに、質問の所有者は 'UNIX Philosophy'でタスクを達成していますが、これはWindowsの男になりたくないと思われますか?
ストゥトンプソン

3
まず第一に、私はその分野でUnixまたは他の何かに対して何もありません。ファイルシステムとデータベースには大きな違いがあり、それが両方の技術が開発された理由です。データベースは、多くの小さなエンティティで動作するように設計されており、ほとんどのファイルシステムよりも優れた機能を発揮します。私はあなたがこれで取ることができる別の道があるかもしれないと単に指摘していました。
ジェロンランドヒー2009年

1
また、Linuxでファイルシステムをデフラグするよりも、dbファイルを「クリーン/バキューム」する方がはるかに簡単です。ほとんど/すべてのfsは、必要ではないと言って、その機能を提供しません。上記のMihaiのコメントに注目すると、それが厳密に真実ではないことがわかります。
グリンゴサーブ

3

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

Q:多くの小さなファイル(SSDではなくHDD)を保存するための最も高性能なLinuxファイルシステムは何ですか?

最高の読み取りパフォーマンスはReiserFSから得られるようです。


Btrfsは、削除以外のすべてにおいて、より良いまたは同等の結果が得られるようです。しかし、300k個のファイルをどのくらいの頻度で削除しますか?私は過去にrfsが好きでしたが、btrfsは将来のためのより良い賭けかもしれません。
グリンゴサーブ

3

私の経験では、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

1

ext3(またはext4)、おそらくJFSがいい解決策だと思います。ext4とbtrfsには注意が必要です(ファイルシステムは扱いにくいです-最新の最新のものを使用する場合は、バックアップを用意してください)。

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

私は確かにXFS に対してお勧めます。悪いファイルシステムだからではなく、作成/削除はコストのかかる操作です。


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

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

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


1
最初のn文字だけでなく、最初と最後の文字を使用する利点は何ですか?
ベネ

それは可能なスキームの1つにすぎません-利点になるかどうかは、インデックス作成に使用される「キー」に依存します。私が見たこの特定のスキームは、組織内の人々のデータを保存するアプリケーションで参照され、このように、彼らはより良いインデックスを取得しました。いつものように、あなたはそれをあなたのデータに適合させ、そしてあなたが正確な答えを見つけるまでプロファイルする必要があります:)

1

ほとんどのFSは、ディレクトリ内に65Kを超えるファイルが詰まっています。それはext4にも当てはまります。Reiserファイルシステムにはその制限はありません(mp3.comの人々はそれを確認するために支払いました)。他のことについてはわかりませんが、それはReiserFSが作成された使用シナリオの1つです。


1
それはRieserFSではなくReiserFSです
ダニエルリコウスキ2009年

今週末、ext4に1000000個のファイルがあるディレクトリがありました。あなたがしないlsかタブ補完をしない限り、それは速く働きます。おそらくインデックスが原因です。
オレタンゲ

ext4にはdir_index拡張子があり、1つのディレクトリ内の多くのファイルを高速化します。
アルフォンス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.