許容範囲内のパフォーマンスを得ながら、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に保つようにしてください。
Be [〜＃〜] very [〜＃〜]ディレクトリ分割の選択方法に注意してください。 「a/b/c」は私にとって災害のレシピのように聞こえます...
最初のレベルで100エントリ、2番目のレベルで100エントリ、3番目のレベルで100エントリのように、いくつかのディレクトリの深い構造を作成するだけではありません。私はそこに行って、それをやって、ジャケットを手に入れ、パフォーマンスが数百万ファイルのクラッパーで行われたときにジャケットを再構築する必要がありました。 :-)
「複数のディレクトリ」レイアウトを実行するクライアントがあり、最終的にディレクトリごとに1〜5個のファイルを配置することになり、これによりファイルが強制終了されました。このディレクトリ構造で「du」を実行するには、3〜6時間かかります。ここでの救い主はSSDであり、彼らはアプリケーションのこの部分を書き換える気がなく、SSDはこの時間を数時間から数分に短縮しました。
問題は、ディレクトリルックアップの各レベルでシークが行われ、シークに非常にコストがかかることです。ディレクトリのサイズも要因です。そのため、ディレクトリを大きくするのではなく小さくすることは大きな利点です。
ディレクトリあたりのファイル数についての質問に答えるために、1,000は「最適」と言われたと聞きましたが、10,000でのパフォーマンスは問題ないようです。
したがって、私がお勧めするのは1レベルのディレクトリで、各レベルは2文字のディレクトリで、大文字と小文字と数字で構成され、最上位レベルの約3800のディレクトリに対応しています。その後、3800個のファイルを含むサブディレクトリを持つ14Mファイル、または3Mファイルのサブディレクトリごとに約1,000個のファイルを保持できます。
私は別のクライアントのためにこのような変更を行いました、そしてそれは大きな違いを作りました。
postmark などのベンチマークツールを使用して、さまざまなディレクトリサイズをテストすることをお勧めします。これは、キャッシュサイズ（OSとディスクサブシステムの両方）など、特定の変数に依存する変数がたくさんあるためです。環境。
私の個人的な経験則では、20kファイル以下のディレクトリサイズを目標としていますが、最大100kファイル/ディレクトリで比較的まともなパフォーマンスを見てきました。
次のようなフォルダにすべてのファイルがあります。
uploads/[date]/[hour] /to.png
パフォーマンスの問題はありません。
まともな負荷の下で十分なメモリを備えた非常に強力なサーバーで、70,000個のファイルがあらゆる種類の混乱を引き起こす可能性があることを確認できます。 70kファイルが含まれているキャッシュフォルダーを削除すると、Apacheは新しいインスタンスの生成を開始し、最大インスタンス数が255になり、システムがすべての空きメモリを使用しました（仮想インスタンスはそれより低い可能性がありますが、16GB）。どちらにしても、25,000未満に保つことはおそらく非常に慎重な動きです
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未満にするのが理想的です。
うーん、私は この記事は最近 を読みました。基本的に、お気に入りのハッシュアルゴリズムの分布を利用します。 MySQLで署名されたINTの最大値は2147483647です。最後の番号で解決するために、ディレクトリごとのファイル数とサブディレクトリ数を変更することもできます。 -of-sub-directories/files-per-directorysplit for a given data set、but it's find it's empiriprativeエビデンスを最適なディレクトリ/ファイル編成で。 この記事 は、ファイルシステム全体のパフォーマンスの違い（いくつかの興味深いメトリック）についての洞察を提供しますが、最適な組織については何も提供しません。
私の経験では、最善の方法は、事前にファイル構造を過度に設計しないことです。少なくとも1つの他の回答で述べたように、パフォーマンスの問題を解決するファイルシステム拡張があります。
私が頻繁に遭遇する問題は、管理の端でのユーザビリティです。ディレクトリ内のファイル数を減らすためにできる最小限の作業は、おそらく現在必要なアプローチです。
sqrt（3_000_000）== 1732
単一のディレクトリにある数千のファイルは、私には合理的に聞こえます。あなた自身の状況についてあなた自身の裁判官になってください。これを実現するには、ファイルを単一レベルのハッシュディレクトリに分割して、ディレクトリあたりの平均ファイル数がディレクトリ数とほぼ同じになるようにします。
あなたの例を考えると、これは./a/abc.ext、./ab/abc.ext、./abc/abc.ext、...になります。
ファイルの広がりは、実際のファイル名に大きく依存します。この手法を、それぞれfoobar???.txtという名前の100万個のファイルのディレクトリに適用するとします。各ファイル名のMD5合計から特定のビット数の値に基づいてハッシュするなど、より均等な拡散を実現する方法がありますが、これは、達成しようとしていることに対してはやり過ぎになると思います。
考えすぎだと思います。単一の追加レベルのディレクトリを選択し、均等にバランスをとることができた場合、1732 *ディレクトリと1ディレクトリあたり1732ファイルができます。
数百億のファイルが必要になることを計画していない限り、1000〜100,000の間の数を選択して、良い結果を得ることができます。
* 300万の平方根。