NTFSパフォーマンスと大量のファイルおよびディレクトリ


183

NTFSを搭載したWindowsは、大量のファイルとディレクトリでどのように機能しますか?

パフォーマンスの問題やその他の問題が発生する前に、単一のディレクトリに配置できるファイルまたはディレクトリの制限に関するガイダンスはありますか?

たとえば、100,000個のフォルダを含むフォルダを作成しても問題ありませんか?



関連する質問の回答は、ここで受け入れられた回答よりも劣っています。
エリックJ.

この実装は便利
Ghominejad '12

回答:


271

ここには、何千万ものファイルを含むフォルダがある環境を持つ誰かからのアドバイスがあります。

  1. フォルダーは、インデックス情報(子ファイルと子フォルダーへのリンク)をインデックスファイルに格納します。子供が多い場合、このファイルは非常に大きくなります。フォルダーである子とファイルである子を区別しないことに注意してください。唯一の違いは、その子のコンテンツが、子のフ​​ォルダーインデックスまたは子のファイルデータのどちらかであるということです。注:私はこれを多少簡略化していますが、これは全体的に重要です。
  2. インデックスファイルは断片化されます。断片化しすぎると、そのフォルダーにファイルを追加できなくなります。これは、許可されるフラグメントの数に制限があるためです。仕様によるものです。サポートインシデントコールでマイクロソフトに確認しました。したがって、フォルダーに含めることができるファイル数の理論上の制限は数十億ですが、断片化の制限に最初に達するので、数千万のファイルにヒットし始めると幸運です。
  3. しかし、すべてが悪いわけではありません。ツールcontig.exeを使用して、このインデックスを最適化できます。インデックスのサイズは小さくなりませんが(数千万のファイルで数ギグに達する可能性があります)、フラグメントの数を減らすことができます。注:ディスクデフラグツールは、フォルダのインデックスをデフラグしません。ファイルデータをデフラグします。contig.exeツールのみがインデックスをデフラグします。参考:これを使用して、個々のファイルのデータをデフラグすることもできます。
  4. デフラグを行う場合は、フラグメントの最大数に達するまで待機しないでください。手遅れになるまで待っていたため、デフラグできないフォルダがあります。次のテストでは、いくつかのファイルをそのフォルダーから別のフォルダーに移動して、最適化できるかどうかを確認します。これが失敗した場合は、1)新しいフォルダーを作成する必要があります。2)ファイルのバッチを新しいフォルダーに移動します。3)新しいフォルダをデフラグします。これが完了するまで#2と#3を繰り返し、次に4)古いフォルダーを削除し、新しいフォルダーの名前を変更して古いフォルダーと一致させます。

あなたの質問にもっと直接答えるために:あなたが10万のエントリを見ているなら、心配はありません。自分をノックアウトしてください。数千万のエントリを表示している場合は、次のいずれかを実行します。

a)それらをサブフォルダーに分割する計画を立てます(たとえば、1億個のファイルがあるとしましょう。1つの大きなフォルダーに保存するよりも、フォルダーごとに100,000個のファイルしか持たないように、1000個のフォルダーに保存することをお勧めします。これはフラグメントの最大数に達する可能性が高い単一の大きなインデックスではなく、1000のフォルダインデックスを作成します。

b)定期的にcontig.exeを実行して、大きなフォルダーのインデックスをデフラグした状態に保つ計画を立てます。

あなたが退屈している場合のみ、以下をお読みください。

実際の制限はフラグメントの数ではなく、フラグメントへのポインターを格納するデータセグメントのレコード数です。

つまり、ディレクトリデータのフラグメントへのポインタを格納するデータセグメントがあります。ディレクトリデータは、ディレクトリが格納したと思われるサブディレクトリとサブファイルに関する情報を格納します。実際、ディレクトリは何も「保存」しません。記憶媒体自体は線形であるため、階層の錯覚をユーザーに提示するのは、単なる追跡およびプレゼンテーション機能です。


5
に関する詳細情報はどこにありますか?contig.exeサーバーにありません。Google検索で、サブディレクトリやフォルダインデックスのデフラグについて言及されていないこのtechnetページが返されました。
エヴァンキャロル2010年

35
マイクロソフトエンジニアとのテクニカルコールでコンティグとフォルダーインデックスの断片化について知りました。それは、彼らの役に立たないレベル1〜3層の技術サポートを通過することで、お尻に大きな痛みを感じました。(ええと... chkdskを実行してみましたか?Windowsエクスプローラーでフォルダーを開くことはできますか?フォルダーのアクセス許可を確認できますか?)FOOL!私はここに7日間座って、何千万ものファイルがあるドライブをchkdskがドライブをスキャンするのを待つつもりはありません!!
MrB

5
@ ss2k- contig.exeディレクトリをポイントするだけで、私それでうまくいくと思いcontig -a .ます:C:\temp\viele-Dateien is in 411 fragments Summary: Number of files processed : 1 Average fragmentation : 411 frags/file
Lumi

3
@GPhilo数百万のファイルを使用すると、SSDでパフォーマンスが低下することを確認できます。私もフォルダーをデフラグしようとしましたが、コンティグはそれに対して何もしませんでした。完了したかのように動作しましたが、実行前と実行後に同じ断片化を示しました。
Bram Vanroy 2017

1
インデックスをデフラグするためにContigを実行するという点では、contigを、、c:\my\big\directoryまたはのどちらc:\my\big\directory\*で実行する必要があり$mftますか?(または何か他に?)
スティーブンR

47

短いファイル名を作成するとパフォーマンスが低下するというパフォーマンス上の問題もあります。フォルダーに300kを超えるファイルがある場合は、短いファイル名の作成をオフにすることをお勧めします[1]。最初の6文字の固有性が低いほど、これは問題になります。

[1] http://technet.microsoft.comからNTFSがどのように機能するか、「300,000」を検索してください


3
ここに引用を追加しますIf you use large numbers of files in an NTFS folder (300,000 or more), disable short-file name generation for better performance, and especially if the first six characters of the long file names are similar.。「300,000」ヒントの検索を省略します。ところで:「300」と入力するだけで十分です(ここではクリップボードの必要はありません)
Wolf

32

私は最大20億(2 ^ 32)のファイルをホストするファイル構造を構築しており、Navigate + Read Performanceの急激な低下を示す次のテストを実行しました。ソリッドステートドライブ(NTFSディレクトリあたり約250ファイルまたは120ディレクトリ)( SSD):

  • ファイルパフォーマンスは、250ファイルと1000ファイルの間で50%低下します。
  • ディレクトリのパフォーマンスは、120〜1000ディレクトリの間で60%低下します。
  • 1000を超える数値の値は比較的安定したままです

興味深いことに、ディレクトリとファイルの数はそれほど干渉しません。

したがって、レッスンは次のとおりです。

  • 250を超えるファイル番号には2の因数がかかります
  • 120を超えるディレクトリには2.5の係数がかかります
  • Windows 7のFile-Explorerは、大きな#Filesまたは#Dirsを処理できますが、それでもユーザビリティは悪いです。
  • サブディレクトリの導入は高価ではありません

これはデータです(ファイルとディレクトリごとに2つの測定値):

(FOPS = File Operations per Second)
(DOPS = Directory Operations per Second)

#Files  lg(#)   FOPS    FOPS2   DOPS    DOPS2
   10   1.00    16692   16692   16421   16312
  100   2.00    16425   15943   15738   16031
  120   2.08    15716   16024   15878   16122
  130   2.11    15883   16124   14328   14347
  160   2.20    15978   16184   11325   11128
  200   2.30    16364   16052   9866    9678
  210   2.32    16143   15977   9348    9547
  220   2.34    16290   15909   9094    9038
  230   2.36    16048   15930   9010    9094
  240   2.38    15096   15725   8654    9143
  250   2.40    15453   15548   8872    8472
  260   2.41    14454   15053   8577    8720
  300   2.48    12565   13245   8368    8361
  400   2.60    11159   11462   7671    7574
  500   2.70    10536   10560   7149    7331
 1000   3.00    9092    9509    6569    6693
 2000   3.30    8797    8810    6375    6292
10000   4.00    8084    8228    6210    6194
20000   4.30    8049    8343    5536    6100
50000   4.70    7468    7607    5364    5365

そしてこれはテストコードです:

[TestCase(50000, false, Result = 50000)]
[TestCase(50000, true, Result = 50000)]
public static int TestDirPerformance(int numFilesInDir, bool testDirs) {
    var files = new List<string>();
    var dir = Path.GetTempPath() + "\\Sub\\" + Guid.NewGuid() + "\\";
    Directory.CreateDirectory(dir);
    Console.WriteLine("prepare...");
    const string FILE_NAME = "\\file.txt";
    for (int i = 0; i < numFilesInDir; i++) {
        string filename = dir + Guid.NewGuid();
        if (testDirs) {
            var dirName = filename + "D";
            Directory.CreateDirectory(dirName);
            using (File.Create(dirName + FILE_NAME)) { }
        } else {
            using (File.Create(filename)) { }
        }
        files.Add(filename);
    }
    //Adding 1000 Directories didn't change File Performance
    /*for (int i = 0; i < 1000; i++) {
        string filename = dir + Guid.NewGuid();
        Directory.CreateDirectory(filename + "D");
    }*/
    Console.WriteLine("measure...");
    var r = new Random();
    var sw = new Stopwatch();
    sw.Start();
    int len = 0;
    int count = 0;
    while (sw.ElapsedMilliseconds < 5000) {
        string filename = files[r.Next(files.Count)];
        string text = File.ReadAllText(testDirs ? filename + "D" + FILE_NAME : filename);
        len += text.Length;
        count++;
    }
    Console.WriteLine("{0} File Ops/sec ", count / 5);
    return numFilesInDir; 
}

2
短い名前の生成(8文字の名前の生成)を無効にする必要があるため、2 ^ 8ファイルの後にパフォーマンスが低下します。technet.microsoft.com/en-us/library/cc781134(v=ws.10).aspxを
カイルファルコナー

1
こんにちは、私はこのコマンドラインを使用してそれを試しました:fsutil.exe動作セットdisable8dot3 1再起動後、結果は10000未満のファイル/ディレクトリでほとんど同じでした。記事はそれがより高い数のためにだけ重要であると言います。私が見たのは一般的なパフォーマンスです。SSDの負荷率が高いために劣化している可能性があります(45%ではなく80%が使用されています)
Spoc

とても役に立ちました、ありがとう。他のユーザーが言った数百万の見積もりは、この数値とはかけ離れています。
Adrian Maire、2017年

2
8.3形式の名前の生成を無効にした後でも、既存の8.3形式の名前を取り除く必要があります。そうしないと、既存のファイルの列挙がほとんど改善されません。
スティーブンR


15

100,000で大丈夫です。

(偶発的に)何百万ものファイルで問題が発生しているのを見たことがあります。Explorerでも、60から数千のファイルを数える方法がわからないだけで問題がありましたが、話しているボリュームにはNTFSが適しています。

ご参考までに、技術的な(そして理論的には)ファイルの最大数は、4,294,967,295です。


5
初心者の場合、その大きな数は(2 ^ 32-1)ファイルです。
ミートスペース

8

ローカルアクセスの場合、多数のディレクトリ/ファイルは問題ではないようです。ただし、ネットワーク経由でアクセスしている場合は、数百後に顕著なパフォーマンスヒットが発生します(特にVistaマシンからアクセスした場合(XPからWindows Server w / NTFSへのアクセスは、この点ではるかに高速に実行されたようです))。


4
これがSMB(ネットワークレベル)ではなくNTFS(サーバーのディスクプロトコル)であることを確認しますか?
MSalters 2008年

いいえ、原因を絞り込むための調査はこれ以上行っていません。私が持っている唯一の情報は、上記のとおりです。
Brian Knoblauch 2012

2

N個のエントリを持つフォルダを作成すると、ファイルシステムレベルでN個のアイテムのリストが作成されます。このリストは、システム全体の共有データ構造です。その後、エントリを追加/削除してこのリストを継続的に変更し始める場合、共有データに対して少なくともいくつかのロック競合が発生すると予想されます。この競合は、理論的にはパフォーマンスに悪影響を及ぼす可能性があります。

読み取り専用のシナリオでは、多数のエントリがあるディレクトリのパフォーマンスが低下する理由は想像できません。


1

1つのオンラインライブラリをコピーしているときに、ディレクトリ内のNTFSにある約10万のファイル(それぞれ数MB)を実際に使用しました。

エクスプローラまたは7-zipでディレクトリを開くのに約15分かかります。

でサイトのコピーを作成するwinhttrackと、しばらくすると常にスタックします。また、約1 000 000個のファイルを含むディレクトリも扱いました。最悪なのは、MFTはシーケンシャルにしかトラバースできないということです。

ext3のext2fsdで同じファイルを開くと、ほぼ同じタイミングが得られました。おそらくreiserfs(reiser4fsではない)に移行すると役立つでしょう。

この状況を回避しようとするのがおそらく最善です。

ブロブを使用せずにfsを使用しない独自のプログラムでは、有益な場合があります。これがFacebookが写真を保存する方法です。


「MFTは順番にトラバースすることによってのみ可能になる」ということはどこでわかりますか?MFTにはBツリーが含まれており、Bツリーのようにトラバースされます
phuclv '15
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.