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

Как Windows с NTFS работает с большими объемами файлов и каталогов?

Есть ли какие-либо рекомендации по ограничению количества файлов или каталогов, которые вы можете поместить в один каталог, прежде чем столкнетесь с проблемами производительности или другими проблемами?

Например, папка с 100 000 папок внутри - это нормально?

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

Итак, у вас есть сегмент данных, который хранит указатели на фрагменты данных каталога. В данных каталога хранится информация о подкаталогах и подфайлах, которые якобы хранятся в каталоге. Фактически, каталог ничего не "хранит". Это просто функция отслеживания и презентации, которая представляет иллюзию иерархии для пользователя, поскольку сам носитель данных является линейным.

Ответ 2

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

[1] Как работает NTFS из http://technet.microsoft.com, найдите "300 000"

Ответ 3

Я создаю файловую структуру для размещения до 2 миллиардов (2 ^ 32) файлов и выполнил следующие тесты, которые показывают резкое падение в Navigate + Read Performance около 250 файлов или 120 каталогов в каталоге NTFS на Solid State Drive (SSD):

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

Интересно, что количество каталогов и файлов НЕ сильно мешает.

Итак, уроки:

  • Число файлов выше 250 стоит Фактор 2
  • Каталоги выше 120 стоили Фактор 2,5
  • File-Explorer в 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; 
}

Ответ 4

100 000 должны быть в порядке.

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

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