パフォーマンスの問題とエラーを確認するウェブサイトがあり、何千ものファイルをディレクトリにキャッシュするキャッシュコードが見つかりました。
私はこれが良くないことを知っており、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。