Производительность NTFS и большие объемы файлов и каталогов
Как Windows с NTFS работает с большими объемами файлов и каталогов?
Есть ли какие-либо рекомендации по ограничению количества файлов или каталогов, которые вы можете поместить в один каталог, прежде чем столкнетесь с проблемами производительности или другими проблемами?
Например, папка с 100 000 папок внутри - это нормально?
8 ответов
Вот несколько советов от кого-то, где есть папки, содержащие десятки миллионов файлов.
- Папка хранит информацию индекса (ссылки на дочерние файлы и дочернюю папку) в файле индекса. Этот файл станет очень большим, когда у вас много детей. Обратите внимание, что он не различает дочерний элемент, являющийся папкой, и дочерний элемент, представляющий собой файл. Единственное отличие на самом деле состоит в том, что содержимое этого дочернего элемента является либо индексом дочерней папки, либо данными дочернего файла. Примечание: я несколько упрощаю это, но это ясно.
- Индексный файл будет фрагментирован. Когда он станет слишком фрагментированным, вы не сможете добавлять файлы в эту папку. Это потому, что есть ограничение на количество фрагментов, которые разрешены. Это по замыслу. Я подтвердил это с Microsoft в звонке в службу поддержки. Поэтому, хотя теоретическое ограничение на количество файлов, которое вы можете иметь в папке, составляет несколько миллиардов, удачи вам, когда вы начнете использовать десятки миллионов файлов, так как сначала вы достигнете ограничения фрагментации.
- Однако не все так плохо. Вы можете использовать инструмент: contig.exe для дефрагментации этого индекса. Это не уменьшит размер индекса (который может достигать нескольких гигабайт для десятков миллионов файлов), но вы можете уменьшить количество фрагментов. Примечание. Инструмент дефрагментации диска НЕ будет дефрагментировать индекс папки. Это будет дефрагментировать данные файла. Только инструмент contig.exe будет дефрагментировать индекс. К вашему сведению: вы также можете использовать это для дефрагментации данных отдельного файла.
- Если вы выполняете дефрагментацию, не ждите, пока не достигнете максимального числа фрагментов. У меня есть папка, в которой я не могу дефрагментировать, потому что я ждал, пока не станет слишком поздно. Мой следующий тест - попытаться переместить некоторые файлы из этой папки в другую, чтобы посмотреть, смогу ли я выполнить их дефрагментацию. Если это не удастся, то мне нужно будет 1) создать новую папку. 2) переместить пакет файлов в новую папку. 3) дефрагментировать новую папку. повторите #2 и #3, пока это не будет сделано, а затем 4) удалите старую папку и переименуйте новую папку, чтобы она соответствовала старой.
Чтобы ответить на ваш вопрос более прямо: если вы просматриваете 100000 записей, не беспокойтесь. Иди в себя. Если вы просматриваете десятки миллионов записей, то либо:
а) Планируйте разделить их на подпапки (например, допустим, у вас есть 100 млн файлов. Лучше хранить их в 1000 папок, чтобы у вас было только 100000 файлов в папке, чем хранить их в 1 большой папке. создаст 1000 индексов папок вместо одного большого, который с большей вероятностью достигнет максимального числа фрагментов или
б) Планируйте запуск contig.exe на регулярной основе, чтобы сохранить индекс вашей большой папки дефрагментированным.
Читайте ниже, только если вам скучно.
Фактическое ограничение не на количество фрагментов, а на количество записей в сегменте данных, в котором хранятся указатели на фрагмент.
Итак, у вас есть сегмент данных, в котором хранятся указатели на фрагменты данных каталога. Данные каталога хранят информацию о подкаталогах и подфайлах, которые каталог предположительно хранил. На самом деле, каталог ничего не "хранит". Это просто функция отслеживания и представления, которая создает иллюзию иерархии для пользователя, поскольку сам носитель данных является линейным.
Существуют также проблемы с производительностью, поскольку создание коротких имен файлов замедляет работу. Microsoft рекомендует отключить создание коротких имен файлов, если в папке более 300 тыс. Файлов [1]. Чем менее уникальны первые 6 символов, тем больше проблем.
[1] Как NTFS работает с http://technet.microsoft.com/, поиск "300 000"
Я строю файловую структуру для размещения до 2 миллиардов (2^32) файлов и выполнил следующие тесты, которые показывают резкое падение производительности Navigate + Read примерно на 250 файлов или 120 каталогов на каталог NTFS на твердотельном диске (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;
}
100 000 должно быть хорошо.
Я (анекдотично) видел людей, имеющих проблемы со многими миллионами файлов, и у меня были проблемы с Explorer, просто я не знал, как считать более 60 тысяч файлов, но NTFS должна быть хороша для томов, о которых вы говорите.
Если вам интересно, техническое (и я надеюсь, теоретическое) максимальное количество файлов: 4 294 967 295
Для локального доступа большое количество каталогов / файлов, кажется, не проблема. Однако, если вы получаете доступ к нему через сеть, после нескольких сотен заметное снижение производительности (особенно при доступе с компьютеров Vista (в этом отношении XP на Windows Server с NTFS, по-видимому, работает намного быстрее)).
У меня был реальный опыт работы с около 100 000 файлов (каждый по несколько МБ) в NTFS в каталоге при копировании одной онлайн-библиотеки.
Открытие каталога с помощью Explorer или 7-zip занимает около 15 минут.
Написание сайта с копией winhttrack всегда застрянет через некоторое время. Это касается также каталога, содержащего около 1 000 000 файлов. Я думаю, что хуже всего то, что MFT может проходить только последовательно.
Открытие того же самого под ext2fsd на ext3 дало почти такой же расчет времени. Вероятно, может помочь переход на reiserfs (не reiser4fs).
Попытка избежать этой ситуации, вероятно, является лучшей.
Для ваших собственных программ, использующих BLOB-объекты без любой fs, может быть полезным. Это то, что делает Facebook для хранения фотографий.
Когда вы создаете папку с N записями, вы создаете список из N элементов на уровне файловой системы. Этот список представляет собой общесистемную общую структуру данных. Если вы затем начнете непрерывно изменять этот список, добавляя / удаляя записи, я ожидаю, по крайней мере, некоторой конкуренции за блокировку из-за общих данных. Это утверждение - теоретически - может негативно повлиять на производительность.
Для сценариев только для чтения, я не могу представить причину снижения производительности каталогов с большим количеством записей.
Помимо NTFS, на поведение и работу NTFS также могут влиять сервер, на котором размещена файловая система, и клиент, использующий файловую систему [удаленно] . Клиенты обычно используют протокол SMB для доступа к общим сетевым ресурсам. Каждая версия Windows Server и Client может вести себя по-разному.
Кроме того, можно настроить сам SMB. В качестве отправной точки см.
Настройка производительности файловых серверов | Microsoft Learnhttps://learn.microsoft.com/en-us/windows-server/administration/ Performance-tuning/role/file-server/