共有nfsファイルシステム上で深いディレクトリにアクセスする場合、大きなディレクトリ構造のパフォーマンスを調べようとしています。構造体は4レベルのネストされたディレクトリで、各レベルには1024のディレクトリが含まれています。 （ルートでは1024、特定のサブディレクトリでは1024など）。大規模なディレクトリ構造、ネットワーク化されたアプリケーションのパフォーマンス
このファイルシステムは、ユーザーが個人情報のためにアクセスするネットワークリポジトリにあります。データは複数のサーバーに複製され、負荷分散されますが、各マシンは常に適切な負荷を持ちます。
第4レベルにユーザーが探していた情報が含まれていた場合、パフォーマンスはどれくらい悪くなりますか？すべてが異なるサブディレクトリにアクセスしていたら？これはinode情報をキャッシュすることで解決できますか？
これはしばらく検索してきましたが、主に大きなディレクトリ構造ではなく、大きなファイルに関する情報を検索しています。
私はそのことを一度やりました。正確な数字は覚えていないが、深さは8レベル、各レベルのサブディレクトリは10個だと思う（ユーザID 87654321はディレクトリ8/7/6/5/4/3/2/1 /にマップする。 iirc（10^10 = 10000000000ディレクトリ、それほどうまくいきません）レベルごとのサブディレクトリ数を増やし、レベル数を減らして問題を解決しました。しかし、あなたのファイルシステムがあなたが予期している種類のファイルとディレクトリ数をサポートしていることを確認してください。
ここでの答えは、お使いのオペレーティングシステムに大きく依存します。詳細情報を提供できますか？私は、Linux上のファイルオープン時間は、数万の小さなディレクトリサイズまで合理的であることを発見しましたが、あなたのものと同じ大きさのディレクトリ構造では何のテストも試していません（1024から4番目のパワーは1,099,511,627,776です？それは地球の人口の180倍のようなものですよね？）
1024個のフォルダを生成するテストアプリケーションを作成したいと思えば、8個のレベルが反復され、各フォルダにはいくつかの番号100〜1000？）のファイルをランダムに検索してアクセスします。
複数のパスでアクセス時間を追跡し、要件に合致するかどうかを確認します。
は、XFSを見てください。..
それは私の仕事でのプロジェクトのためです。いくつかのレイヤーはユーザーアカウントに関連し、他のレイヤーはそれらのアカウントの設定/ウィジェット/アドオンなどに使用されます。ファイルシステムはLinuxサーバー上でext3になると私は信じています。