Производительность NTFS и большие объемы файлов и каталогов

существуют также проблемы с производительностью при создании коротких имен файлов, замедляющих работу. Корпорация Майкрософт рекомендует отключить создание коротких файлов, если у вас более 300k файлов в папке [1]. Чем менее уникальны первые 6 символов, тем больше это проблема.

[1] как работает NTFS от http://technet.microsoft.com, поиск "300,000"

Я создаю файловую структуру для размещения до 2 миллиардов (2^32) файлов и выполнил следующие тесты, которые показывают резкое падение производительности навигации + чтения примерно в 250 файлах или 120 каталогах на каталог NTFS на твердотельном диске (SSD):

• производительность файла падает на 50% между 250 и 1000 файлов.
• производительность каталога падает на 60% между 120 и 1000 каталогами.
• значения для чисел > 1000 остаются относительно стабильными

интересно, что количество каталогов и файлов существенно не вмешивается.

Итак, уроки:

• номера файлов выше 250 стоят в 2 раза
• каталоги выше 120 стоят в 2,5 раза
• файл-проводник в Windows 7 может обрабатывать большие # файлы или #Dirs, но удобство использования по-прежнему плохо.
• введение подкаталогов не дорого

Это данные (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 должно быть нормально.

Я (анекдотально) видел людей, имеющих проблемы со многими миллионами файлов, и у меня были проблемы с Explorer, просто не имея понятия, как считать последние 60-что-то тысяч файлов, но NTFS должен быть хорош для томов, о которых вы говорите.

в случае, если вам интересно, технический (и я надеюсь теоретической) максимальное количество файлов: 4,294,967,295

для локального доступа большое количество каталогов / файлов не кажется проблемой. Однако, если вы обращаетесь к нему по сети, есть заметный удар по производительности после нескольких сотен (особенно при доступе с компьютеров Vista (XP к Windows Server w/NTFS, похоже, работает намного быстрее в этом отношении)).

при создании папки с N записями создается список из N элементов на уровне файловой системы. Этот список представляет собой общесистемную общую структуру данных. Если вы начнете постоянно изменять этот список, добавляя / удаляя записи, я ожидаю, по крайней мере, некоторого конфликта блокировки по общим данным. Это утверждение - теоретически - может негативно повлиять на производительность.

для сценариев только для чтения я не могу представить никакой причины для снижения производительности каталогов с большими количество записей.

У меня был реальный опыт работы с около 100 000 файлов (каждый несколько Мб) на NTFS в каталоге при копировании одной онлайн-библиотеки.

для открытия каталога с помощью Explorer или 7-zip требуется около 15 минут.

запись копии сайта с помощью winhttrack всегда будет застрять через некоторое время. Он также имел дело с каталогом, содержащим около 1 000 000 файлов. Я думаю, что хуже всего то, что MFT может только последовательно проходить.

открытие того же под ext2fsd на ext3 дали почти такое же время. Вероятно, переход на reiserfs (не reiser4fs) может помочь.

попытка избежать этой ситуации, вероятно, лучше всего.

для ваших собственных программ, использующих blobs без каких-либо fs, может быть полезно. Вот так Facebook для хранения фотографий.