NTFSを搭載したWindowsは、大量のファイルとディレクトリでどのように機能しますか?
パフォーマンスの問題やその他の問題が発生する前に、単一のディレクトリに配置できるファイルまたはディレクトリの制限に関するガイダンスはありますか?
たとえば、100,000個のフォルダを含むフォルダを作成しても問題ありませんか?
NTFSを搭載したWindowsは、大量のファイルとディレクトリでどのように機能しますか?
パフォーマンスの問題やその他の問題が発生する前に、単一のディレクトリに配置できるファイルまたはディレクトリの制限に関するガイダンスはありますか?
たとえば、100,000個のフォルダを含むフォルダを作成しても問題ありませんか?
回答:
ここには、何千万ものファイルを含むフォルダがある環境を持つ誰かからのアドバイスがあります。
あなたの質問にもっと直接答えるために:あなたが10万のエントリを見ているなら、心配はありません。自分をノックアウトしてください。数千万のエントリを表示している場合は、次のいずれかを実行します。
a)それらをサブフォルダーに分割する計画を立てます(たとえば、1億個のファイルがあるとしましょう。1つの大きなフォルダーに保存するよりも、フォルダーごとに100,000個のファイルしか持たないように、1000個のフォルダーに保存することをお勧めします。これはフラグメントの最大数に達する可能性が高い単一の大きなインデックスではなく、1000のフォルダインデックスを作成します。
b)定期的にcontig.exeを実行して、大きなフォルダーのインデックスをデフラグした状態に保つ計画を立てます。
あなたが退屈している場合のみ、以下をお読みください。
実際の制限はフラグメントの数ではなく、フラグメントへのポインターを格納するデータセグメントのレコード数です。
つまり、ディレクトリデータのフラグメントへのポインタを格納するデータセグメントがあります。ディレクトリデータは、ディレクトリが格納したと思われるサブディレクトリとサブファイルに関する情報を格納します。実際、ディレクトリは何も「保存」しません。記憶媒体自体は線形であるため、階層の錯覚をユーザーに提示するのは、単なる追跡およびプレゼンテーション機能です。
contig.exe
サーバーにありません。Google検索で、サブディレクトリやフォルダインデックスのデフラグについて言及されていないこのtechnetページが返されました。
contig.exe
ディレクトリをポイントするだけで、私はそれでうまくいくと思いcontig -a .
ます:C:\temp\viele-Dateien is in 411 fragments Summary: Number of files processed : 1 Average fragmentation : 411 frags/file
c:\my\big\directory
またはのどちらc:\my\big\directory\*
で実行する必要があり$mft
ますか?(または何か他に?)
短いファイル名を作成するとパフォーマンスが低下するというパフォーマンス上の問題もあります。フォルダーに300kを超えるファイルがある場合は、短いファイル名の作成をオフにすることをお勧めします[1]。最初の6文字の固有性が低いほど、これは問題になります。
[1] http://technet.microsoft.comからNTFSがどのように機能するか、「300,000」を検索してください
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」と入力するだけで十分です(ここではクリップボードの必要はありません)
私は最大20億(2 ^ 32)のファイルをホストするファイル構造を構築しており、Navigate + Read Performanceの急激な低下を示す次のテストを実行しました。ソリッドステートドライブ(NTFSディレクトリあたり約250ファイルまたは120ディレクトリ)( SSD):
興味深いことに、ディレクトリとファイルの数はそれほど干渉しません。
したがって、レッスンは次のとおりです。
これはデータです(ファイルとディレクトリごとに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;
}
ローカルアクセスの場合、多数のディレクトリ/ファイルは問題ではないようです。ただし、ネットワーク経由でアクセスしている場合は、数百後に顕著なパフォーマンスヒットが発生します(特にVistaマシンからアクセスした場合(XPからWindows Server w / NTFSへのアクセスは、この点ではるかに高速に実行されたようです))。
1つのオンラインライブラリをコピーしているときに、ディレクトリ内のNTFSにある約10万のファイル(それぞれ数MB)を実際に使用しました。
エクスプローラまたは7-zipでディレクトリを開くのに約15分かかります。
でサイトのコピーを作成するwinhttrack
と、しばらくすると常にスタックします。また、約1 000 000個のファイルを含むディレクトリも扱いました。最悪なのは、MFTはシーケンシャルにしかトラバースできないということです。
ext3のext2fsdで同じファイルを開くと、ほぼ同じタイミングが得られました。おそらくreiserfs(reiser4fsではない)に移行すると役立つでしょう。
この状況を回避しようとするのがおそらく最善です。
ブロブを使用せずにfsを使用しない独自のプログラムでは、有益な場合があります。これがFacebookが写真を保存する方法です。