サブディレクトリの数は、Linuxのドライブの読み取り/書き込みパフォーマンスにどのように影響しますか？

Linux CentOSサーバーにEXT3フォーマットのドライブがあります。これはウェブアプリのデータドライブであり、すべてのユーザーアカウントのディレクトリが含まれています（ユーザー数は25,000人です）。各フォルダには、そのユーザーがアップロードしたファイルが含まれています。全体として、このドライブには約250GBのデータが含まれています。

これらすべてのディレクトリを使用してドライブを構成すると、ドライブの読み取り/書き込みパフォーマンスに影響がありますか？それは私が気付いていない他のパフォーマンスの側面に影響を与えますか？

このように構造化することで本質的に悪い点や悪い点はありますか？おそらくファイルシステムの間違った選択でしょうか？

私は最近2つのデータドライブをマージしてみましたが、EXT3は32,000のサブディレクトリに制限されていることに気付きました。これはなぜだろうと思いました。データベース内のIDに対応する一意のIDが各ファイルにあることを考えると、この方法で作成したのはばかげているようです。ああ...

これは、自分の環境で自分のオプションを簡単にテストし、結果を比較するのが簡単です。はい、ディレクトリの数が増えると、パフォーマンスに悪影響があります。はい、他のファイルシステムは、これらの障壁を回避したり、影響を軽減したりするのに役立ちます。

XFSファイルシステムは、より優れたディレクトリ構造のこのタイプのためです。ext4はおそらく現在は問題ありません。サブディレクトリとファイルの数が増えると、ディレクトリへのアクセスと操作が遅くなります。これはext3で非常に顕著で、XFSではそれほど顕著ではありません。

答えはファイルシステムの選択ほど単純ではありません。正気のファイルシステムはずっと前にディレクトリの線形リストの使用を停止しました。つまり、ディレクトリ内のエントリの数はファイルのアクセス時間に影響しません...

ある場合を除いて。

実際、エントリの数に関係なく、各操作は高速で効率的ですが、一部のタスクでは操作の数が増加しています。明らかに、単純なものlsを実行するには長い時間がかかり、すべてのiノードが読み取られてソートされるまで、何も表示されません。こうls -U（ソートされていないが）あなたはそれが死んではありません見ることができるので少し役立ちますが、鋭敏時間を短縮しません。それほど明白ではないのは、ワイルドカードの展開では、すべてのファイル名をチェックする必要があり、ほとんどの場合、inode全体も読み取る必要があるようです。

要するに、アプリケーション（シェルアクセスを含む）がワイルドカードを使用しないことが確実であると確信できれば、後悔せずに巨大なディレクトリを取得できます。ただし、コードにワイルドカードが潜んでいる可能性がある場合は、ディレクトリをそれぞれ1,000エントリ以下に保つことをお勧めします。

編集：

最近のすべてのファイルシステムは、大きなディレクトリに適切なデータ構造を使用しているため、特定のファイルのiノードを見つける必要がある1つの操作は、巨大なディレクトリでも非常に高速になります。

しかし、ほとんどのアプリケーションは単一の操作だけを行うわけではありません。それらのほとんどは、完全なディレクトリまたはワイルドカード一致のいずれかを行います。それらはすべてのエントリを読み取る必要があるため、これらは何があっても遅くなります。

たとえば、「foo-000000.txt」から「foo-999999.txt」までの100万個のファイルと1つの「natalieportman.jpeg」を含むディレクトリがあるとします。これらは高速になります：

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

これらは失敗しますが、すぐに失敗します。

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

結果が非常に少ない場合でも、これらは遅くなります。失敗した場合でも、すべてのエントリをスキャンした後に失敗します。

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

まず、ext3パーティションにdir_indexフラグが設定されていることを確認します。

sudo dumpe2fs /dev/sdaX |grep --color dir_index

見つからない場合は、有効にすることができます。ファイルシステムをアンマウントしてから実行する必要があります：

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

次に、ファイルシステムをマウントします。

ディレクトリあたりのext3 32,000の名前の制限に達するまで、違いはありません。ext4にアップグレードすると、ext4が持つ他の利点と同様に、それを回避できます。

1つのディレクトリ内にあるエントリ（ファイル、ディレクトリ）が多いほど、アクセスが遅くなります。これはすべてのファイルシステムに当てはまりますが、他のものよりも悪いものもあります。

より良い解決策は、次のようにディレクトリ階層を作成することです。

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

さらにパフォーマンスが必要な場合は、複数のレベルを拡張できます。

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

ほとんどのメールシステムは、メールキューファイルでこのトリックを使用します。

また、一部のファイルシステムでは、過去にディレクトリ内に多数のエントリがあると、そのディレクトリへのアクセスが遅くなることがわかりました。やるls -ldディレクトリエントリ自体のサイズを確認するには、ディレクトリに。数MB以上で、ディレクトリが比較的空の場合は、パフォーマンスが低下している可能性があります。邪魔にならないようにディレクトリの名前を変更し、同じ名前、権限、所有権で新しいディレクトリを作成してから、古いディレクトリの内容を新しいディレクトリに移動します。私はこのトリックを何度も使用して、ファイルシステムによって速度が低下したメールサーバーを大幅に高速化しました。

私は最近、数千万のファイルと数十万のディレクトリを作成する必要があるストレージサーバーを開発しました。XFSをext4およびreiserfsと比較しました。私の場合、ext4はXFSよりもわずかに高速であることがわかりました。Reiserは興味深いものでしたが、制限があったため削除されました。また、ext4はext3よりも大幅に高速であることがわかりました。

ディレクトリごとに多くのファイルを取得すると、ファイルのオープン時間が悪化し始めます。ファイルI / Oは行いません。ファイルの削除時間も影響を受けます。ただし、ext4では遅くなりません。ただし、ext3ではかなり目立ちます。XFSとext4はこれでかなり高速です。

最後にXFSを見て、ext4よりもXFSを使用する利点と欠点を比較検討していたとき、XFSでのデータ損失の報告を見つけました。これがまだ問題なのか、それとも問題だったのかはわかりませんが、不安を取り除いて対処しました。ext4はUbuntuのデフォルトのfsであるため、XFSで簡単に勝ちました。

したがって、管理の観点から役立つタイラーの提案に加えて、ext4にアップグレードすることをお勧めします。ディレクトリごとの制限は、ext4で64000エントリです。

もう1つの利点は、fsck時間が大幅に短縮されることです。腐敗の問題は一度もありません。

ext4の良い点は、ext3ボリュームをext4にマウントして試してみることです。参照：ライブシステムのext3からext4ファイルシステムへの移行

そのリンクからの引用：

ext3の制限の影響を受けず、リスクを冒す気がない場合は、価値がないかもしれません。一方、移行手順が正常に完了すると、システムのパフォーマンスが向上し、ファイルシステムチェックが短縮され、信頼性が向上し、悪影響はありません。

だから、先に行き、それを試してみてください。最初にバックアップを提案します。

これを行うと、いくつかの結果が生じる可能性があります。主なものは、IO読み取り/書き込みです。それを超えて、それはそのタイプのデータを（その規模で）扱う非常に恐ろしい方法です。

過去には、XFSを使用してExt3の制限を回避して成功しました。

ファイルシステムの内容の最初のリストは、システムがすべてのディレクトリ/ファイル情報を読み取るまでしばらくかかります。カーネルに情報がキャッシュされるようになったため、補足操作はより高速になります。

管理者が定期的にcronで 'find / somepath 2>＆1> / dev / null'を実行してキャッシュをアクティブに保ち、パフォーマンスを向上させるのを見てきました。

いくつか質問がありますが、ボトルネックの可能性があります。

まず、これはCentOS 5または6システムですか？6には、このような状況での影響を測定するのに理想的なblktraceという素晴らしいツールがあるからです。

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

次に、bttを使用して出力を解析し、ボトルネックがどこにあるか、アプリケーション、ファイルシステム、スケジューラ、ストレージ-IOがほとんどの時間を費やしているコンポーネントを取得できます。

今、理論的にあなたの質問に来ると、それは明らかにiノードの数を増やし、ディレクトリ内の新規または既存のファイルまたはディレクトリを作成またはアクセスし続けると、アクセス時間が増加します。カーネルはより広大なファイルシステム階層をたどる必要があるため、間違いなくオーバーヘッドになります。

注意すべきもう1つの点は、ディレクトリの数を増やすと、inodeとdentryのキャッシュ使用量が増加し、RAMの消費量が増えることです。これはスラブメモリの下にあるため、サーバーのメモリが不足している場合は、別のポイントです。

実世界の例について言えば、最近、高度にネストされたext3 fsで初めてサブディレクトリを作成するのに約20秒かかるのに対し、ext4では約4秒かかることがわかりました。これは、ブロック割り当てが異なるファイルシステムでどのように構造化されているかによるものです。XFSまたはext4を使用している場合、パフォーマンスが向上することは言うまでもありませんが、最小限の場合もあります。

したがって、ファイルシステムの正しい選択を求めているだけの場合、ext3は少し時代遅れです。それ以上のデータやベンチマークなしで私が提供できるのはそれだけです。

これはCentOS 5のオプションではなく、CentOS 6のオプションの程度はわかりませんが、BツリーまたはB *ツリーベースのソリューション、つまりBTRFSは、特定のパフォーマンスが大幅に向上しない場合でも、一貫性を提供するだろうと直感していますシナリオは、1人だけが自分の貴重なデータを明確な良心をもって委託できる場合（私はまだそうしません）。

しかし、余裕があれば、テストすることができます。