単一ディレクトリ内のファイルシステムの多数のファイル
わかりました。それほど大きくはありませんが、平均サイズが30kbのファイルが約60,000個格納されているディレクトリを使用する必要があります（これは要件であるため、ファイル数が少ないサブディレクトリに単純に分割することはできません）。
ファイルはランダムにアクセスされますが、一度作成されると、同じファイルシステムへの書き込みはありません。私は現在Ext3を使用していますが、非常に時間がかかります。助言がありますか？
XFSを検討する必要があります。ファイルシステムとディレクトリレベルの両方で非常に多数のファイルをサポートし、B +ツリーのデータ構造により、多数のエントリがあってもパフォーマンスは比較的安定しています。
デザインについて詳しく説明する多数の論文や出版物に Wikiのページ があります。私はそれを試してみて、現在のソリューションに対してベンチマークすることをお勧めします。
この記事の著者は、ファイル数が多いファイルシステムでのパフォーマンスの問題をいくつか掘り下げ、さまざまなファイルシステムext3、ext4、およびXFSのパフォーマンスを比較しています。これはスライドショーとして利用できます。 https://events.static.linuxfound.org/slides/2010/linuxcon2010_wheeler.pdf
Ext3のディレクトリにある多くのファイルについては、姉妹サイトで詳しく説明されています stackoverflow.com
私の意見では、ext3の1つのディレクトリにある60 000個のファイルは理想とはほど遠いですが、他の要件によっては、それで十分かもしれません。
私はもっとたくさんのファイルを保存するアプリケーションを書いていますが、私のファイルは1000万個あり、そのうちの1000万個を複数のディレクトリに分割します。
ext3は、主にデフォルトの「リンクリスト」の実装が原因で遅くなります。したがって、1つのディレクトリに多くのファイルがある場合、別のディレクトリを開いたり作成したりするのに時間がかかります。 ext3で使用できるhtreeインデックスと呼ばれるものがあります。しかし、それはファイルシステムの作成でのみ利用可能です。ここを参照してください： http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/
とにかくファイルシステムを再構築する必要があるため、ext3の制限により、ext4（またはXFS）の使用を検討することをお勧めします。 ext4はファイルが小さいほど少し高速で、再構築も高速だと思います。 Htreeインデックスは、私の知る限り、ext4のデフォルトです。私は実際にはJFSやReiserの経験はありませんが、以前から推奨されていると聞いています。
実際には、おそらくいくつかのファイルシステムをテストします。 ext4、xfs、jfsを試してみて、どれが全体的に最高のパフォーマンスを発揮するか確認してみませんか？
開発者がアプリケーションコードで処理を高速化できると私に言ったのは、「stat + open」呼び出しではなく、「open + fstat」を実行することです。 1つ目は2つ目よりもかなり低速です。あなたがそれに対して何らかのコントロールや影響力を持っているかどうかはわかりません。
Stackoverflowに関する私の投稿はこちらです。 Linuxで最大1,000万のファイルを保存してアクセスする そこには、非常に役立つ回答とリンクがいくつかあります。
OK。 ReiserFS、XFS、JFS、Ext3（dir_hashが有効）、Ext4dev（2.6.26カーネル）を使用して、いくつかの予備テストを行いました。私の第一印象は、すべてが（私の頑丈なワークステーションで）十分に高速であるというものでした-リモートのプロダクションマシンのプロセッサはかなり遅いことがわかりました。
最初のテストでもReiserFSの奇妙さを経験したので、それを除外しました。 JFSは他のすべてよりも33％少ないCPU要件があるようで、リモートサーバーでテストします。十分に機能する場合は、それを使用します。
Tune2fsを使用してdir_indexを有効にすると役立つ場合があります。有効になっているかどうかを確認するには：
Sudo tune2fs -l /dev/sda1 | grep dir_index
有効になっていない場合：
Sudo umount /dev/sda1
Sudo tune2fs -O dir_index /dev/sad1
Sudo e2fsck -D /dev/sda1
Sudo mount /dev/sda1
しかし、私はあなたが間違った道を進んでいるかもしれないと感じています...フラットなインデックスを生成し、それに基づいてランダムに選択するためにいくつかのコードを使用しないでください。次に、サブディレクトリを使用して、より最適化されたツリー構造を作成できます。
ext3以前では、ディレクトリごとに最大32768ファイルをサポートしています。 ext4は、実際のファイル数で最大65536をサポートしますが、それ以上の数を許可します（ほとんどのユーザーの目的には関係なく、ディレクトリにファイルを保存しないだけです）。
また、ディレクトリがext *ファイルシステムに格納される方法は、基本的に1つの大きなリストです。より最近のファイルシステム（Reiser、XFS、JFS）では、それらはBツリーとして格納され、大規模なセットの場合ははるかに効率的です。
ファイル名の代わりにファイルiノードを保存できます。iノード番号へのアクセスは、ファイル名の解決よりもはるかに高速です。
1つのディレクトリにそのような多くのファイルを詰め込みたくない場合は、何らかの構造が必要です。ファイルの最初の文字で始まるサブディレクトリを作成するだけの簡単な方法でも、アクセス時間を改善できます。私が使用したい別のばかげたトリックは、メタ情報でシステムのキャッシュを強制的に更新することです。updatedbを定期的に実行することです。あるウィンドウでslabtopを実行し、別のウィンドウでupdatedbを実行すると、多くのメモリがキャッシュに割り当てられることがわかります。この方法の方がはるかに高速です。