NTFS를 사용하는 Windows는 대량의 파일 및 디렉토리에서 어떻게 작동합니까?
성능 문제 또는 다른 문제가 발생하기 전에 단일 디렉토리에 배치 할 수있는 파일 또는 디렉토리의 한계에 대한 지침이 있습니까?
예를 들어 그 안에 100,000 개의 폴더가있는 폴더가있는 것이 좋습니다?
NTFS를 사용하는 Windows는 대량의 파일 및 디렉토리에서 어떻게 작동합니까?
성능 문제 또는 다른 문제가 발생하기 전에 단일 디렉토리에 배치 할 수있는 파일 또는 디렉토리의 한계에 대한 지침이 있습니까?
예를 들어 그 안에 100,000 개의 폴더가있는 폴더가있는 것이 좋습니다?
답변:
여기에 수천만 개의 파일이 포함 된 폴더가있는 환경을 가진 사람의 조언이 있습니다.
질문에보다 직접적으로 대답하려면 : 100K 항목을보고 있다면 걱정할 필요가 없습니다. 가서 놀아 봐 수천만 개의 항목을보고 있다면 다음 중 하나를 수행하십시오.
a) 파일을 하위 폴더로 세분화 할 계획을 세우십시오 (예 : 100M 파일이 있다고 가정 해보십시오. 파일을 1000 개의 폴더에 저장하여 폴더 당 100,000 개의 파일 만 저장하는 것이 1 개의 큰 폴더에 저장하는 것보다 낫습니다. 최대 조각 수 한도에 도달 할 가능성이 큰 하나의 큰 폴더 대신 1000 개의 폴더 인덱스를 만들거나
b) 큰 폴더의 인덱스 조각 모음을 유지하기 위해 정기적으로 contig.exe를 실행하도록 계획하십시오.
지루할 때만 아래를 읽으십시오.
실제 제한은 프래그먼트 수가 아니라 프래그먼트에 대한 포인터를 저장하는 데이터 세그먼트의 레코드 수에 있습니다.
그래서 당신은 디렉토리 데이터의 조각에 대한 포인터를 저장하는 데이터 세그먼트입니다. 디렉토리 데이터는 디렉토리에 저장된 하위 디렉토리 및 하위 파일에 대한 정보를 저장합니다. 실제로, 디렉토리는 아무것도 "저장"하지 않습니다. 저장 매체 자체가 선형이기 때문에 사용자에게 계층 구조의 환상을 나타내는 추적 및 프리젠 테이션 기능 일뿐입니다.
contig.exe
서버에 없습니다. Google 검색 에서 하위 디렉토리 나 폴더 색인 조각 모음에 대한 언급이없는 이 기술 페이지 를 반환 했습니다 .
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"힌트를 검색 할 필요가 없습니다. BTW : "300"을 입력하면 충분합니다 (= 클립 보드를 작성할 필요가 없습니다)
최대 20 억 개의 (2 ^ 32) 파일을 호스팅하는 파일 구조를 구축하고 있으며 SSD (Solid State Drive)의 NTFS 디렉토리 당 약 250 개 파일 또는 120 개 디렉토리에서 Navigate + Read 성능이 급격히 떨어지는 다음 테스트를 수행했습니다 ( 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 컴퓨터에서 액세스 할 때 (NTFS가 포함 된 XP에서 Windows Server로 NTFS가 훨씬 빠르게 실행되는 것처럼 보임)).
하나의 온라인 라이브러리를 복사하는 동안 디렉토리의 NTFS에있는 약 100,000 개의 파일 (각 몇 MB)에 대한 실제 경험이있었습니다.
탐색기 또는 7-zip으로 디렉토리를 여는 데 약 15 분이 걸립니다.
사이트 사본을 작성 winhttrack
하면 일정 시간이 지나면 항상 중단됩니다. 또한 약 1,000 개의 파일을 포함하는 디렉토리를 처리했습니다. 최악의 점은 MFT가 순차적으로 순회 만 가능하다는 것입니다.
ext3의 ext2fsd에서 같은 것을 열면 거의 같은 타이밍을 얻었습니다. 아마도 reiseer4fs가 아닌 reiserfs로 옮기는 것이 도움이 될 수 있습니다.
이 상황을 피하는 것이 가장 좋습니다.
fs가없는 blob을 사용하는 자체 프로그램의 경우 fs가 도움이 될 수 있습니다. Facebook이 사진을 저장하는 방식입니다.