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

Вот несколько советов от кого-то, у кого есть среда, в которой у нас есть папки, содержащие десятки миллионов файлов.

1. Папка хранит информацию индекса (ссылки на дочерние файлы и дочернюю папку) в файле индекса. Этот файл станет очень большим, когда у вас будет много детей. Обратите внимание, что он не делает различий между дочерним элементом, представляющим собой папку, и дочерним элементом, представляющим собой файл. Единственная разница в том, что содержимое этого дочернего элемента является либо индексом дочерней папки, либо данными дочернего файла. Примечание: я несколько упрощаю это, но это дает понять.
2. Индексный файл будет фрагментирован. Когда он станет слишком фрагментированным, вы не сможете добавлять файлы в эту папку. Это связано с тем, что количество разрешенных фрагментов ограничено. Это по замыслу. Я подтвердил это в Microsoft при обращении в службу поддержки. Поэтому, хотя теоретический предел количества файлов, которые вы можете иметь в папке, составляет несколько миллиардов, удачи, когда вы начнете обрабатывать десятки миллионов файлов, поскольку вы сначала столкнетесь с ограничением фрагментации.
3. Однако не все так плохо. Вы можете использовать инструмент: contig.exe для дефрагментации этого индекса. Это не уменьшит размер индекса (который может достигать нескольких гигабайт для десятков миллионов файлов), но вы можете уменьшить количество фрагментов. Примечание. Инструмент дефрагментации диска НЕ ​​выполняет дефрагментацию индекса папки. Он будет дефрагментировать данные файла. Только инструмент contig.exe выполнит дефрагментацию индекса. К вашему сведению: вы также можете использовать это для дефрагментации данных отдельного файла.
4. Если вы ДЕФРАГМИРУЕТЕ, не ждите, пока вы достигнете максимального количества фрагментов. У меня есть папка, в которой я не могу дефрагментировать, потому что я ждал, пока не станет слишком поздно. Мой следующий тест - попытаться переместить некоторые файлы из этой папки в другую, чтобы посмотреть, смогу ли я затем дефрагментировать их. Если это не удастся, то мне нужно будет 1) создать новую папку. 2) переместите пакет файлов в новую папку. 3) дефрагментировать новую папку. повторяйте # 2 и # 3, пока это не будет сделано, а затем 4) удалите старую папку и переименуйте новую папку, чтобы она соответствовала старой.

Чтобы ответить на ваш вопрос более прямо: если вы просматриваете 100 тысяч записей, не беспокойтесь. Идите в нокаут. Если вы смотрите на десятки миллионов записей, то либо:

a) Планируйте разделить их на подпапки (например, допустим, у вас есть 100 миллионов файлов. Лучше хранить их в 1000 папок, чтобы у вас было только 100 000 файлов в папке, чем хранить их в одной большой папке. Это создаст 1000 индексов папок вместо одного большого, который с большей вероятностью достигнет максимального количества фрагментов или

б) Запланируйте запуск contig.exe на регулярной основе, чтобы индекс вашей большой папки оставался дефрагментированным.

Читайте ниже, только если вам скучно.

Фактическое ограничение не на количество фрагментов, а на количество записей сегмента данных, в котором хранятся указатели на фрагмент.

Итак, у вас есть сегмент данных, в котором хранятся указатели на фрагменты данных каталога. Данные каталога хранят информацию о подкаталогах и подфайлах, которые предположительно хранятся в каталоге. На самом деле каталог ничего не «хранит». Это просто функция отслеживания и представления, которая представляет для пользователя иллюзию иерархии, поскольку сам носитель данных является линейным.

Также есть проблемы с производительностью, связанные с созданием коротких имен файлов, что замедляет работу. Microsoft рекомендует отключать создание коротких имен файлов, если в папке более 300 КБ файлов [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 может обрабатывать большие файлы #Files или #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; 
}

100000 должно быть хорошо.

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

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

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

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

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

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

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

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

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

Лучше всего попытаться избежать этой ситуации.

Для ваших собственных программ использование BLOB-объектов без каких-либо fs может быть полезным. Вот как Facebook хранит фотографии.