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

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

---

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

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

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

---

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

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를 실행하도록 계획하십시오.

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

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

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

---

짧은 파일 이름 생성으로 인해 성능이 느려지는 성능 문제도 있습니다. 폴더에 300k 개가 넘는 파일이있는 경우 짧은 파일 이름 만들기를 해제하는 것이 좋습니다 [1]. 처음 6자가 고유하지 않을수록 문제가 더 많습니다.

[1] http://technet.microsoft.com의 NTFS 작동 방식 에서 "300,000"을 검색하십시오.

---

최대 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; 
}

---

100,000 should be fine.

I have (anecdotally) seen people having problems with many millions of files and I have had problems myself with Explorer just not having a clue how to count past 60-something thousand files, but NTFS should be good for the volumes you're talking.

In case you're wondering, the technical (and I hope theoretical) maximum number of files is: 4,294,967,295

---

For local access, large numbers of directories/files doesn't seem to be an issue. However, if you're accessing it across a network, there's a noticeable performance hit after a few hundred (especially when accessed from Vista machines (XP to Windows Server w/NTFS seemed to run much faster in that regard)).

---

When you create a folder with N entries, you create a list of N items at file-system level. This list is a system-wide shared data structure. If you then start modifying this list continuously by adding/removing entries, I expect at least some lock contention over shared data. This contention - theoretically - can negatively affect performance.

For read-only scenarios I can't imagine any reason for performance degradation of directories with large number of entries.

---

I had real experience with about 100 000 files (each several MBs) on NTFS in a directory while copying one online library.

It takes about 15 minutes to open the directory with Explorer or 7-zip.

Writing site copy with winhttrack will always get stuck after some time. It dealt also with directory, containing about 1 000 000 files. I think the worst thing is that the MFT can only by traversed sequentially.

Opening the same under ext2fsd on ext3 gave almost the same timing. Probably moving to reiserfs (not reiser4fs) can help.

Trying to avoid this situation is probably the best.

For your own programs using blobs w/o any fs could be beneficial. That's the way Facebook does for storing photos.

참고URL : https://stackoverflow.com/questions/197162/ntfs-performance-and-large-volumes-of-files-and-directories