Wydajność NTFS i duże ilości plików i katalogów

Jak działa system Windows z systemem plików NTFS w przypadku dużych woluminów plików i katalogów?

Czy istnieją jakieś wskazówki dotyczące limitów plików lub katalogów, które można umieścić w jednym katalogu, zanim wystąpią problemy z wydajnością lub inne problemy?

Np. Czy posiadanie folderu zawierającego 100 000 folderów jest w porządku?

Oto kilka porad od kogoś ze środowiska, w którym mamy foldery zawierające dziesiątki milionów plików.

1. Folder przechowuje informacje o indeksie (łącza do plików podrzędnych i folderu podrzędnego) w pliku indeksu. Ten plik będzie bardzo duży, jeśli masz dużo dzieci. Pamiętaj, że nie rozróżnia między dzieckiem, które jest folderem, a dzieckiem, które jest plikiem. Jedyną różnicą jest to, że zawartość tego dziecka jest albo indeksem folderu dziecka, albo danymi pliku dziecka. Uwaga: nieco to upraszczam, ale o to chodzi.
2. Plik indeksu zostanie pofragmentowany. Gdy zostanie zbyt pofragmentowany, nie będzie można dodawać plików do tego folderu. Wynika to z faktu, że dozwolona jest liczba fragmentów. To jest z założenia. Potwierdziłem to w firmie Microsoft w zgłoszeniu do pomocy technicznej. Więc chociaż teoretyczny limit liczby plików, które możesz mieć w folderze, to kilka miliardów, powodzenia, gdy zaczniesz bić dziesiątki milionów plików, ponieważ najpierw uderzysz w ograniczenie fragmentacji.
3. Jednak nie jest tak źle. Możesz użyć narzędzia: contig.exe do defragmentacji tego indeksu. Nie zmniejszy to rozmiaru indeksu (który może osiągnąć nawet kilka koncertów dla dziesiątek milionów plików), ale możesz zmniejszyć liczbę fragmentów. Uwaga: Narzędzie Defragmentacja dysku NIE defragmentuje indeksu folderu. Defragmentuje dane pliku. Tylko narzędzie contig.exe defragmentuje indeks. FYI: Możesz go również użyć do defragmentacji danych pojedynczego pliku.
4. Jeśli wykonasz defragmentację, nie czekaj, aż osiągniesz maksymalną liczbę limitów fragmentów. Mam folder, w którym nie mogę defragmentować, ponieważ czekałem, aż będzie za późno. Mój następny test to próba przeniesienia niektórych plików z tego folderu do innego folderu, aby sprawdzić, czy mogę go wtedy zdefragmentować. Jeśli to się nie powiedzie, musiałbym 1) utworzyć nowy folder. 2) przenieś partię plików do nowego folderu. 3) defragmentuj nowy folder. powtarzaj # 2 i # 3, aż to zrobisz, a następnie 4) usuń stary folder i zmień nazwę nowego folderu, aby pasował do starego.

Aby odpowiedzieć bardziej bezpośrednio na twoje pytanie: Jeśli patrzysz na 100 000 wpisów, nie martw się. Idź się znokautować. Jeśli patrzysz na dziesiątki milionów wpisów, to albo:

a) Zaplanuj podzielenie ich na podfoldery (np. powiedzmy, że masz 100 mln plików. Lepiej jest przechowywać je w 1000 folderach, aby mieć tylko 100 000 plików na folder niż przechowywać je w 1 dużym folderze. To utworzy 1000 indeksów folderów zamiast jednego dużego, który z większym prawdopodobieństwem przekroczy limit liczby fragmentów lub

b) Zaplanuj regularne uruchamianie contig.exe, aby defragmentować indeks dużego folderu.

Przeczytaj poniżej tylko, jeśli się nudzisz.

Rzeczywisty limit nie dotyczy liczby fragmentów, ale liczby rekordów segmentu danych, który przechowuje wskaźniki do fragmentu.

Więc masz segment danych, który przechowuje wskaźniki do fragmentów danych katalogu. Dane katalogu przechowują informacje o podkatalogach i pod-plikach, które rzekomo przechowywano w katalogu. W rzeczywistości katalog niczego nie „przechowuje”. To tylko funkcja śledzenia i prezentacji, która przedstawia iluzję hierarchii dla użytkownika, ponieważ sam nośnik pamięci jest liniowy.

Występują również problemy z wydajnością związane z tworzeniem krótkich nazw plików, które spowalniają pracę. Microsoft zaleca wyłączenie tworzenia krótkich nazw plików, jeśli w folderze znajduje się ponad 300 000 plików [1]. Im mniej unikalnych jest pierwszych 6 znaków, tym bardziej jest to problemem.

[1] Jak działa NTFS ze strony http://technet.microsoft.com , wyszukaj „300 000”

Buduję strukturę plików, aby pomieścić do 2 miliardów (2 ^ 32) plików i wykonałem następujące testy, które wykazały gwałtowny spadek wydajności nawigacji + odczytu przy około 250 plikach lub 120 katalogach na katalog NTFS na dysku SSD ( SSD):

• Wydajność pliku spada o 50% między 250 a 1000 plików.
• Wydajność katalogu spada o 60% między 120 a 1000 katalogów.
• Wartości dla liczb> 1000 pozostają względnie stabilne

Co ciekawe, liczba katalogów i plików NIE przeszkadza znacząco.

Więc lekcje to:

• Numery plików powyżej 250 kosztują współczynnik 2
• Katalogi powyżej 120 kosztują współczynnik 2,5
• Eksplorator plików w systemie Windows 7 może obsługiwać duże pliki # lub katalogi, ale użyteczność jest nadal zła.
• Wprowadzenie podkatalogów nie jest drogie

To są dane (2 pomiary dla każdego pliku i katalogu):

(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

A to jest kod testowy:

[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 powinno być w porządku.

Widziałem (anegdotycznie) ludzi, którzy mają problemy z wieloma milionami plików i sam miałem problemy z Eksploratorem, po prostu nie mając pojęcia, jak liczyć ponad 60-tysięcy tysięcy plików, ale NTFS powinien być dobry dla woluminów, o których mówisz.

Jeśli się zastanawiasz, techniczna (i mam nadzieję teoretyczna ) maksymalna liczba plików wynosi: 4 294 967 295

W przypadku lokalnego dostępu duża liczba katalogów / plików nie wydaje się stanowić problemu. Jeśli jednak uzyskujesz dostęp do niego przez sieć, zauważalny jest spadek wydajności po kilkuset (szczególnie, gdy dostęp jest uzyskiwany z komputerów Vista (XP do Windows Server z NTFS wydawał się działać pod tym względem znacznie szybciej)).

Podczas tworzenia folderu zawierającego N wpisów tworzona jest lista N elementów na poziomie systemu plików. Ta lista jest ogólnosystemową wspólną strukturą danych. Jeśli następnie zaczniesz ciągle modyfikować tę listę, dodając / usuwając wpisy, spodziewam się przynajmniej pewnej rywalizacji o blokadę względem współdzielonych danych. Spór ten - teoretycznie - może negatywnie wpłynąć na wydajność.

W przypadku scenariuszy tylko do odczytu nie wyobrażam sobie żadnego powodu obniżenia wydajności katalogów z dużą liczbą pozycji.

Miałem prawdziwe doświadczenie z około 100 000 plików (każde kilka MB) na NTFS w katalogu podczas kopiowania jednej biblioteki online.

Otwarcie katalogu za pomocą Eksploratora lub 7-zip zajmuje około 15 minut.

Pisanie kopii strony winhttrackzawsze się zacina po pewnym czasie. Zajmował się także katalogiem zawierającym około 1 000 000 plików. Myślę, że najgorsze jest to, że MFT można tylko przechodzić kolejno.

Otwarcie tego samego w ext2fsd na ext3 dało prawie taki sam czas. Prawdopodobnie przejście na reiserfs (nie reiser4fs) może pomóc.

Próbowanie uniknięcia tej sytuacji jest prawdopodobnie najlepsze.

W przypadku własnych programów korzystających z obiektów blob bez żadnego fs może być korzystne. Tak robi Facebook do przechowywania zdjęć.