共有の nfs ファイルシステムで深いディレクトリにアクセスする場合、大規模なディレクトリ構造のパフォーマンスがどうなるかを調べようとしています。構造が過度に大きくなり、ネストされたディレクトリが 4 レベルになり、各レベルに 1024 個のディレクトリが含まれます。(ルートで 1024、特定のサブディレクトリで 1024 など)。
このファイルシステムは、ユーザーが個人情報のためにアクセスするネットワーク リポジトリ上にあります。データは複数のサーバーに複製され、負荷が分散されますが、それでも各マシンには常に適切な負荷がかかります。
4 番目のレベルにユーザーが探している情報が含まれている場合、パフォーマンスはどの程度低下しますか? すべてが異なるサブディレクトリにアクセスしていたら? これは inode 情報をキャッシュすることで解決できますか?
私はしばらくこれを検索してきましたが、大きなディレクトリ構造ではなく、主に大きなファイルに関する情報を見つけています。
職場で一度やったことがあります。正確な数字は覚えていませんが、8 レベルの深さで、各レベルに 10 のサブディレクトリがあったと思います (ユーザー ID 87654321 はディレクトリ 8/7/6/5/4/3/2/1/ にマップされます)。ファイルシステムの i ノード数の制限、iirc (10^10 = 10000000000 ディレクトリ、良くない) で問題が発生し始めました。レベルごとにより多くのサブディレクトリに切り替え、レベルを大幅に減らしました。問題はなくなりました。あなたの状況はより管理しやすいように思えます。 、それでも、あなたのファイルシステムがあなたが予想している種類のファイルとディレクトリ数をサポートすることを確認してください。
テスト アプリを作成して 1024 個のフォルダーを生成し、8 レベル下に反復処理して、各フォルダーにサイズ 1 KB のファイルをいくつか (100 ～ 1000?) 格納し、ファイルをランダムに見つけてアクセスしたいだけのようです。
複数のパスにわたるアクセス時間を追跡し、それが要件を満たしているかどうかを確認します。
ここでの答えは、お使いのオペレーティング システムに大きく依存します。さらに情報を提供していただけますか? Linux でのファイルのオープン時間は、数万の小さなディレクトリ サイズまで妥当であることがわかりましたが、あなたのような大きなディレクトリ構造でテストを試みたことはありません (1024 の 4 乗が 1,099,511,627,776 であることはご存知でしょう)。 ? そして、それは地球の人口の 180 倍のようなものですよね?)