パフォーマンスの問題とエラーを確認するウェブサイトがあり、何千ものファイルをディレクトリにキャッシュするキャッシュコードが見つかりました。
私はこれが良くないことを知っており、I / Oが遅くなり、潜在的なinodeの問題について聞きました。
キャッシュコードを修正する方法を知っていますが、問題は現時点で修正コストが非常に多いということです。
質問：私がこのように生きると、どのような最悪の状況が起こりますか？ウェブサイトはどうなりますか？ （現在、この単一キャッシュディレクトリには400,000個のファイルがあります）
私はUbuntuを初めて使います。私はこれがトピックから少し外れている可能性があることを知っています。しかし、私はこれが「システム」の問題であり、stackoverflowの「プログラミング」セクションに属していないと思います。
ありがとうございます！
修正する:ファイルシステムはUFSです。
答え1
状況はやや驚くべきです。超高速ファイルシステム本番Linuxをインストールするための珍しいファイルシステムです。 Linux での UFS 書き込みアクセスは通常、カーネルで明示的に有効にする必要があります。実験的なものと考える数年間:
CONFIG_UFS_FS_WRITE：UFSファイルシステムの書き込みサポート（危険）
UFSパーティションに書き込むには、ここでYを選択してください。これは実験的なので、事前にUFSパーティションをバックアップする必要があります。
多くの既存のファイルシステムと同様に、UFS はディレクトリでシーケンシャルファイルルックアップを使用します。検索時間はファイル数に応じて直線的に増加するため、多くのファイルを含むディレクトリではパフォーマンスの問題が発生します。 BSDでは、UFSは通常基本ファイルシステム、この問題は直接発生します。ディハッシュ、ディレクトリのハッシュテーブルのルックアップによってパフォーマンスが大幅に向上します。
私が知る限り、LinuxでのUFSサポートはDirhashを使用しません。したがって、ディレクトリ内のファイルの数が増えると、パフォーマンスの問題がますます多く発生する可能性があります。 400Kファイルはシーケンシャルアクセスの面で大量を占め、大幅なパフォーマンス低下を予想することができます。
サブディレクトリ間でファイルを分割すると、順次アクセスの問題を効果的に管理できます。あるいは、より複雑なファイルストレージ構造をサポートするファイルシステムに移行することもできます。例えば、XFS実装する大規模ディレクトリへの高速ファイルアクセス使用してB+ツリー。
2番目の質問はinodeについてです。通常、ファイルシステムのinodeの数は固定されており、これは通常、ファイルシステムが作成されるときに使用可能なスペースの量によって異なります。たとえば、/etc/mke2fs.confextファイルシステムのデフォルトのinode比（xバイトあたりのinode数）を保存します。
通常、この数は生成するファイルの数よりはるかに大きいので、心配しないでください。ただし、以下をdf -i使用してinodeの使用量を確認できます。 inodeの制限が実際に問題になる可能性がある場合、ディレクトリを操作することは役に立ちません。なぜなら、inodeはディレクトリとは別にファイルシステム全体に適用される概念だからです。この場合、ファイルシステムを再生成し、inodeパラメータを適切に設定する必要があります（-i）mkfs。
答え2
一般的なUNIX（inodeベース）ファイルシステム（UFSを含む）では、生成するすべてのファイルまたはディレクトリがinodeを使用すると言うのが合理的な近似です。ディレクトリにファイル数が多いからといってこれは変わりません。
説明するアプローチの一般的な問題は次のとおりです。
- ファイルシステムは、検索と生成を高速化するために、ディレクトリルックアップにハッシュまたはツリーデータ構造を使用します。単一のディレクトリにファイルが多いほど、速度が遅くなります。ハッシュの場合、衝突が発生したときにこれらの速度低下が非常に目立つように見えることがある。
- 一般的なUnixコマンド（特にソートとシェルグローブの拡張）には問題がありますが、
ls通常はファイルシステムが遅くなる前に問題が発生します。 - ディレクトリに新しいファイルが追加され、より多くのブロックが割り当てられると、ますます断片化され、アクセスするにはより多くのディスクIOが必要になります。
最新のファイルシステム（ext3/4）は、Bツリーと同様のデータ構造を使用して、ディスクデータの一部としてディレクトリの順序を維持します。私はUFS実装がメモリ内ハッシュを使用していると思います（FreeBSDの使用とドキュメントに基づいており、Linux上のUFSの直接的な経験はほとんどありません）。なぜなら、オンディスク形式はハッシュを使用しないからです。
以下は良いUFS情報とリンクです。https://serverfault.com/questions/53416/max-total-files-in-a-directory-in-freebsd-6-ufs
最も可能性の高い最悪のシナリオは、ある時点でこのディレクトリにアクセスしたときに深刻で悪化する速度低下を経験することです。この時点に達すると、修正するのは面倒になります（sendmailキューが爆発的に増加した経験に照らして見たとき）。
システムを監視してチャートを作成することをお勧めします。待つまだわからない場合は、時間をかけて調べてくださいiotop。slabtop
可能であれば、キャッシュディレクトリに1000個のファイルが作成される時間を測定し、それを空のディレクトリのファイルと比較していくつかの簡単な実験を試すことをお勧めします。