NTFS 성능 및 대용량 파일 및 디렉토리


183

NTFS를 사용하는 Windows는 대량의 파일 및 디렉토리에서 어떻게 작동합니까?

성능 문제 또는 다른 문제가 발생하기 전에 단일 디렉토리에 배치 할 수있는 파일 또는 디렉토리의 한계에 대한 지침이 있습니까?

예를 들어 그 안에 100,000 개의 폴더가있는 폴더가있는 것이 좋습니다?



관련 질문에 대한 답변이 여기에서 허용되는 답변보다 열등합니다.
Eric J.

이 구현은 유용 할 수 있습니다 github.com/acrobit/AcroFS
Ghominejad에게

답변:


271

여기에 수천만 개의 파일이 포함 된 폴더가있는 환경을 가진 사람의 조언이 있습니다.

  1. 폴더는 색인 정보 (하위 파일 및 하위 폴더에 대한 링크)를 색인 파일에 저장합니다. 자녀가 많은 경우이 파일이 매우 커집니다. 폴더 인 자식과 파일 인 자식을 구분하지 않습니다. 유일한 차이점은 그 하위의 내용이 하위 폴더 색인 또는 하위 파일 데이터라는 것입니다. 참고 : 나는 이것을 다소 단순화하고 있지만 이것이 요점을 얻습니다.
  2. 색인 파일이 조각화됩니다. 조각이 너무 많으면 해당 폴더에 파일을 추가 할 수 없습니다. 허용되는 조각 수에 제한이 있기 때문입니다. 의도적으로 설계된 것입니다. 지원 인시던트 호출에서 Microsoft에 확인했습니다. 따라서 폴더에 저장할 수있는 파일 수에 대한 이론적 인 제한은 수십억이지만, 조각화 제한에 먼저 도달 할 때 수천만 개의 파일을 기록 할 때 행운을 빕니다.
  3. 그러나 모두 나쁘지는 않습니다. contig.exe 도구를 사용 하여이 인덱스를 조각 모음 할 수 있습니다 . 인덱스의 크기는 줄이지 ​​않지만 (1 억 개의 파일에 대해 최대 몇 기가에이를 수 있음) 조각 수를 줄일 수 있습니다. 참고 : 디스크 조각 모음 도구는 폴더 색인을 조각 모음하지 않습니다. 파일 데이터를 조각 모음합니다. contig.exe 도구 만 인덱스 조각 모음을 수행합니다. 참고 :이 파일을 사용하여 개별 파일의 데이터를 조각 모음 할 수도 있습니다.
  4. 조각 모음을 수행하는 경우 최대 조각 수 제한에 도달 할 때까지 기다리지 마십시오. 너무 늦을 때까지 기다렸 기 때문에 조각 모음을 할 수없는 폴더가 있습니다. 다음 테스트는 해당 파일을 다른 폴더로 옮겨서 조각 모음이 가능한지 확인하는 것입니다. 이것이 실패하면 1) 새 폴더를 만드는 것입니다. 2) 파일 배치를 새 폴더로 옮깁니다. 3) 새 폴더를 조각 모음하십시오. 이 작업이 완료 될 때까지 # 2 & # 3을 반복 한 다음 4) 기존 폴더를 제거하고 이전 폴더와 일치하도록 새 폴더의 이름을 바꿉니다.

질문에보다 직접적으로 대답하려면 : 100K 항목을보고 있다면 걱정할 필요가 없습니다. 가서 놀아 봐 수천만 개의 항목을보고 있다면 다음 중 하나를 수행하십시오.

a) 파일을 하위 폴더로 세분화 할 계획을 세우십시오 (예 : 100M 파일이 있다고 가정 해보십시오. 파일을 1000 개의 폴더에 저장하여 폴더 당 100,000 개의 파일 만 저장하는 것이 1 개의 큰 폴더에 저장하는 것보다 낫습니다. 최대 조각 수 한도에 도달 할 가능성이 큰 하나의 큰 폴더 대신 1000 개의 폴더 인덱스를 만들거나

b) 큰 폴더의 인덱스 조각 모음을 유지하기 위해 정기적으로 contig.exe를 실행하도록 계획하십시오.

지루할 때만 아래를 읽으십시오.

실제 제한은 프래그먼트 수가 아니라 프래그먼트에 대한 포인터를 저장하는 데이터 세그먼트의 레코드 수에 있습니다.

그래서 당신은 디렉토리 데이터의 조각에 대한 포인터를 저장하는 데이터 세그먼트입니다. 디렉토리 데이터는 디렉토리에 저장된 하위 디렉토리 및 하위 파일에 대한 정보를 저장합니다. 실제로, 디렉토리는 아무것도 "저장"하지 않습니다. 저장 매체 자체가 선형이기 때문에 사용자에게 계층 구조의 환상을 나타내는 추적 및 프리젠 테이션 기능 일뿐입니다.


5
에 대한 자세한 정보를 찾을 수있는 곳은 contig.exe서버에 없습니다. Google 검색 에서 하위 디렉토리 나 폴더 색인 조각 모음에 대한 언급이없는 이 기술 페이지 를 반환 했습니다 .
Evan Carroll

35
Microsoft 엔지니어와의 기술 통화에서 contig 및 폴더 인덱스 조각화에 대해 알았습니다. 쓸모없는 레벨 1-3의 기술 지원을 통과하는 것은 엉덩이에 큰 고통이었습니다. (어 ... chkdsk를 실행 해 보셨습니까? Windows 탐색기에서 폴더를 열어 보시겠습니까? 폴더 권한을 확인할 수 있습니까?) FOOL! 나는 당신의 망할 chkdsk가 수천만 개의 파일을 가진 드라이브를 스캔하기를 기다리는 7 일 동안 여기에 앉아 있지 않을 것입니다 !!
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의 성능이 여전히 저하됨을 확인할 수 있습니다. 폴더도 조각 모음을 시도했지만 contig는 폴더에 아무것도하지 않았습니다. 마치 마치 완료된 것처럼 작동했지만 실행 전후에 동일한 조각화가 표시되었습니다.
Bram Vanroy

1
된 Contig 인덱스를 조각 모음 실행의 측면에서, 나는에 인접 실행해야 c:\my\big\directory하거나, c:\my\big\directory\*또는에 $mft? (또는 다른 것?)
Stephen 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"힌트를 검색 할 필요가 없습니다. BTW : "300"을 입력하면 충분합니다 (= 클립 보드를 작성할 필요가 없습니다)
Wolf

32

최대 20 억 개의 (2 ^ 32) 파일을 호스팅하는 파일 구조를 구축하고 있으며 SSD (Solid State Drive)의 NTFS 디렉토리 당 약 250 개 파일 또는 120 개 디렉토리에서 Navigate + Read 성능이 급격히 떨어지는 다음 테스트를 수행했습니다 ( SSD) :

  • 파일 성능은 250-1000 파일 사이에서 50 % 감소합니다.
  • 120-1000 디렉토리 사이에서 디렉토리 성능이 60 % 감소합니다.
  • 1000보다 큰 숫자의 값은 상대적으로 안정적으로 유지됩니다.

흥미롭게도 디렉토리 및 파일 수는 크게 방해하지 않습니다.

수업은 다음과 같습니다.

  • 250을 초과하는 파일 번호는 2의 계수
  • 120 이상의 디렉토리는 2.5의 요소를 소비합니다
  • Windows 7의 File-Explorer는 큰 #Files 또는 #Dir을 처리 할 수 ​​있지만 유용성은 여전히 ​​나쁩니다.
  • 하위 디렉토리를 소개하는 것은 비싸지 않습니다

이것은 데이터입니다 (각 파일 및 디렉토리에 대해 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 behavior set disable8dot3 1 재부팅 후 결과는 10000 개 미만의 파일 / 디렉토리에 대해 거의 동일합니다. 이 기사는 숫자가 클수록 중요하다고 말합니다. 내가 본 것은 일반적인 성능이었습니다. SSD의 더 높은 부하율로 인해 성능이 저하 될 수 있습니다 (45 % 대신 80 %가 찼습니다)
Spoc

매우 유용합니다. 감사합니다. 다른 사용자들이 말한 수백만의 추정치는이 수치와는 거리가 멀다.
Adrian Maire

2
8.3 이름 생성을 비활성화 한 후에도 기존 8.3 이름 을 제거 해야 합니다. 그렇지 않으면 기존 파일 열거가 거의 개선되지 않습니다.
Stephen R


15

100,000은 괜찮을 것입니다.

나는 사람들이 수백만 개의 파일에 문제가있는 것을 보았고 (60 개가 넘는 수천 개의 파일을 계산하는 방법에 대한 단서가없는 Explorer 자체에 문제가 있었지만 NTFS는 말한 볼륨에 좋을 것입니다.

궁금한 점이 있으면 기술적으로 (및 이론적으로는 ) 최대 파일 수는 4,294,967,295입니다.


5
시작되지 않은 경우, 그 큰 수는 (2 ^ 32-1) 파일입니다.
meatspace

8

로컬 액세스의 경우 많은 디렉토리 / 파일이 문제가되지 않는 것 같습니다. 그러나 네트워크를 통해 액세스하는 경우 수백 후에 눈에 띄는 성능 저하가 발생합니다 (특히 Vista 컴퓨터에서 액세스 할 때 (NTFS가 포함 된 XP에서 Windows Server로 NTFS가 훨씬 빠르게 실행되는 것처럼 보임)).


4
이것이 SMB (네트워크 레벨)가 아닌 NTFS (서버의 디스크 프로토콜)인지 확인하십시오.
MSalters

아니요, 원인을 좁히기 위해 더 이상 연구하지 않았습니다. 내가 가진 유일한 정보는 위에 자세히 설명되어 있습니다.
Brian Knoblauch

2

N 개의 항목이있는 폴더를 만들면 파일 시스템 수준에서 N 개의 항목 목록이 만들어집니다. 이 목록은 시스템 전체의 공유 데이터 구조입니다. 그런 다음 항목을 추가 / 제거 하여이 목록을 지속적으로 수정하기 시작하면 공유 데이터에 대한 잠금 경합이 적어도 예상됩니다. 이론적으로 이러한 경합 은 성능에 부정적인 영향을 줄 수 있습니다.

읽기 전용 시나리오의 경우 항목 수가 많은 디렉토리의 성능이 저하되는 이유를 상상할 수 없습니다.


1

하나의 온라인 라이브러리를 복사하는 동안 디렉토리의 NTFS에있는 약 100,000 개의 파일 (각 몇 MB)에 대한 실제 경험이있었습니다.

탐색기 또는 7-zip으로 디렉토리를 여는 데 약 15 분이 걸립니다.

사이트 사본을 작성 winhttrack하면 일정 시간이 지나면 항상 중단됩니다. 또한 약 1,000 개의 파일을 포함하는 디렉토리를 처리했습니다. 최악의 점은 MFT가 순차적으로 순회 만 가능하다는 것입니다.

ext3의 ext2fsd에서 같은 것을 열면 거의 같은 타이밍을 얻었습니다. 아마도 reiseer4fs가 아닌 reiserfs로 옮기는 것이 도움이 될 수 있습니다.

이 상황을 피하는 것이 가장 좋습니다.

fs가없는 blob을 사용하는 자체 프로그램의 경우 fs가 도움이 될 수 있습니다. Facebook이 사진을 저장하는 방식입니다.


"MFT가 순차적으로 순회 만 가능"할 수있는 곳이 어디인지 확실하지 않습니까? MFT는 B- 트리를 포함하고 B- 트리처럼 순회합니다
phuclv
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.