web-dev-qa-db-ja.com

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

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

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

例えば。その中に100,000個のフォルダーがあるフォルダーがあるのは問題ありませんか？

windowsperformancefilesystemsntfs
177
James Newton-King

数千万のファイルを含むフォルダーがある環境を持っている人からのアドバイスがあります。

  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を定期的に実行して、大きなフォルダーのインデックスを最適化した状態に保つ計画を立てます。

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

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

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

264
MrB

また、ファイル名を短くすると作成が遅くなるため、パフォーマンスの問題が発生します。フォルダー[1]に30万を超えるファイルがある場合は、短いファイル名の作成をオフにすることをお勧めします。最初の6文字の一意性が低いほど、これは問題になります。

[1] NTFSの仕組み from http://technet.Microsoft.com 、「300,000」を検索

46
Tony Lee

最大20億（2 ^ 32）個のファイルをホストするファイル構造を構築し、次のテストを実行して、ソリッドステートドライブ上の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; 
}
29
Spoc

100,000で十分です。

私は（逸話的に）何百万ものファイルで問題を抱えている人を見てきましたし、私はエクスプローラで自分自身に問題を抱えていました。過去60から数千のファイルを数える方法がわかりませんが、NTFSはあなたが話しているボリュームに適しているはずです。

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

15
Oli

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

8
Brian Knoblauch

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

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

2
Constantin

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

Explorerまたは7-Zipでディレクトリを開くには約15分かかります。

winhttrackを使用してサイトのコピーを作成すると、しばらくすると常にスタックします。また、約1 000 000ファイルを含むディレクトリも処理しました。最悪の事態は、MFTが順番にしか通過できないことです。

Ext3のext2fsdで同じものを開くと、ほぼ同じタイミングが得られました。おそらくreiserfs（reiser4fsではない）に移行することが役立つ場合があります。

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

任意のfsなしのblobを使用する独自のプログラムの場合、有益である可能性があります。 Facebookが写真を保存する方法です。

1
ximik