1つのext3ディレクトリ内のファイルの最大数は、許容可能なパフォーマンスを得ていますか？

私はext3ディレクトリに書き込むアプリケーションを持っていますが、それはやがて約300万のファイルに成長しました。言うまでもなく、このディレクトリのファイル一覧を読むのは耐えられないほど遅いです。

ext3のせいにしません。適切な解決策は、./a/b/c/abc.extのみを使用するのではなく、などのサブディレクトリにアプリケーションコードを書き込むことでした./abc.ext。

私はそのようなサブディレクトリ構造に変更していますが、私の質問は単純です：許容されるパフォーマンスを得ながら、1つのext3ディレクトリにおよそいくつのファイルを保存する必要がありますか？あなたの経験は？

または言い換えれば、300万個のファイルを構造体に保存する必要があると仮定した場合、./a/b/c/abc.ext構造体の深さはいくつになりますか？

明らかにこれは正確に答えることができない質問ですが、私は球場の見積もりを探しています。

このdir_index機能をサポートするディストリビューションがあれば、1つのディレクトリに200,000個のファイルを簡単に保存できます。ただし、安全のために、約25,000のままにしておきます。なしではdir_index、5,000のままにしてください。

ことが非常にディレクトリ分割を選択する方法は注意。「a / b / c」は私にとって災害のレシピのように聞こえます...

盲目的に、いくつかのディレクトリの深層構造、たとえば、第1レベルで100エントリ、第2レベルで100エントリ、第3レベルで100エントリを作成しないでください。私はそこに行って、それをして、ジャケットを手に入れて、数百万のファイルでクラッパーのパフォーマンスが上がると、ジャケットを再構築しなければなりませんでした。:-)

「複数のディレクトリ」レイアウトを実行し、ディレクトリごとに1〜5個のファイルを配置するクライアントがあり、これによりファイルが強制終了されました。このディレクトリ構造で「du」を実行するのに3〜6時間。ここでの救世主はSSDであり、彼らはアプリケーションのこの部分を書き換えたくありませんでした。SSDはこの時間を数時間から数分に短縮しました。

問題は、ディレクトリルックアップの各レベルでシークが行われ、シークが非常に高価になることです。ディレクトリのサイズも要因であるため、ディレクトリを大きくするのではなく小さくすることは大きなメリットです。

ディレクトリごとにいくつのファイルがあるかという質問に答えるには、1,000が「最適」と言われたと聞きましたが、10,000でのパフォーマンスは問題ないようです。

したがって、私がお勧めするのは、1レベルのディレクトリです。各レベルは、大文字と小文字と数字で構成される2文字の長さのディレクトリで、最上位の約3800個のディレクトリに対応します。その後、3800ファイルを含むサブディレクトリを持つ14Mファイル、または3Mファイルのサブディレクトリあたり約1,000ファイルを保持できます。

私は別のクライアントに対してこのような変更を行いましたが、大きな違いをもたらしました。

特定の環境に依存するキャッシュサイズ（OSとディスクサブシステムの両方）などの変数が多数あるため、postmarkなどのベンチマークツールでさまざまなディレクトリサイズをテストすることをお勧めします。

私の個人的な経験則では、ディレクトリサイズが2万以下のファイルを目指していますが、ディレクトリあたり最大10万のファイルで比較的まともなパフォーマンスが見られます。

私はすべてのファイルを次のようなフォルダに移動します：

uploads / [日付] / [時間] /yo.png

パフォーマンスの問題はありません。

http://en.wikipedia.org/wiki/Ext3#Functionality-これは、ディレクトリが約32000のサブディレクトリしか持つことができないことに言及していますが、ファイルには言及していません。

http://roopindersingh.com/2008/05/10/ext3-handling-large-number-of-files-in-a-directory/

また、Experts Exchangeは嫌いですが、この質問に関するコメントを読んで、ディレクトリごとに10〜15,000未満にするのが理想的です。

適切な負荷の下で十分なメモリを備えた非常に強力なサーバーで、70,000個のファイルがあらゆる種類の混乱を引き起こす可能性があることを確認できます。70kファイルが含まれるキャッシュフォルダーを削除しようとすると、255で最大になり、システムがすべての空きメモリ（仮想インスタンスはそれよりも低いかもしれないが16 GB）を使用するまで、Apacheが新しいインスタンスを生成し始めました。いずれにせよ、25,000未満に保つことはおそらく非常に慎重な動きです。

私の経験では、最善のアプローチは、事前にファイル構造を過剰に設計しないことです。他の少なくとも1つの回答で述べたように、パフォーマンスの問題を解決するファイルシステム拡張機能があります。

私が頻繁に遭遇した問題は、管理上の使いやすさです。ディレクトリ内のファイル数を減らすためにできる最小限の作業は、おそらく今必要なアプローチです。

sqrt（3_000_000）== 1732

単一のディレクトリにある数千のファイルは、私にとって理にかなっています。自分の状況を判断するのはあなた自身です。これを実現するには、ファイルを単一レベルのハッシュディレクトリに分割して、ディレクトリあたりの平均ファイル数がディレクトリ数とほぼ同じになるようにしてください。

あなたの例を考えると、このようになり./a/abc.ext、./ab/abc.ext、./abc/abc.ext、...。

ファイルの広がりは、実際のファイル名に大きく依存します。この手法を、それぞれがという名前の100万ファイルのディレクトリに適用することを想像してくださいfoobar???.txt。各ファイル名のMD5合計から特定のビット数の値に基づいてハッシュするなど、より均一な広がりを達成する方法がありますが、私はあなたが達成しようとしているものに対してはやり過ぎだと思います。

うーん、最近この記事を読みました。基本的に、お気に入りのハッシュアルゴリズムの分布を活用します。MySQLで署名されたINTの最大値は2147483647です。また、ディレクトリごとのファイル数とサブディレクトリの数を変更して、最終的なサブディレクトリ/ファイルの数を決定することもできます。特定のデータセットのディレクトリごとの分割ですが、最適なディレクトリ/ファイル組織に関する経験的証拠を見つけることは困難です。 この記事では、ファイルシステム間のパフォーマンスの違い（興味深いメトリックス）についての洞察を提供していますが、最適な組織については何も提供していません。

あなたはこれについて考えすぎていると思います。単一の追加レベルのディレクトリを選択し、均等にバランスを取ることができた場合、1732 *ディレクトリとディレクトリごとに1732個のファイルがあります。

数百億のファイルを必要とする場合を除いて、1000〜100,000の数値を選択して、良い結果を得ることができます。

* 300万の平方根。