Открывать много маленьких файлов в NTFS слишком медленно

То, что вы пытаетесь сделать, по сути своей сложно сделать эффективно для любой операционной системы. 45 000 подкаталогов требуют большого доступа к диску, независимо от того, как они разделены.

Любой файл размером около 1000 байт считается "большим" с точки зрения NTFS. Если бы существовал способ уменьшить размер большинства файлов данных примерно до 900 байт, можно было бы добиться большей эффективности, если бы данные файла хранились внутри MFT. Тогда получение данных будет не дороже, чем получение временных меток или размера файла.

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

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

Другой стратегией было бы преобразование всех файлов в несколько файлов большего размера, таких как большие файлы .zip, как предлагает @felicepollano, эффективно виртуализируя ваш набор файлов. Произвольный доступ к файлу размером 4000 ГБ по своей природе является гораздо более эффективным и действенным использованием ресурсов, чем доступ к 4 миллиардам файлов размером 1 МБ. Кроме того, перемещение всех данных в подходящий менеджер баз данных (MySQL, SQL Server и т. Д.) Позволит добиться этого и, возможно, даст другие преимущества, такие как простой поиск и легкая стратегия архивирования.

Накладные расходы от 5 до 20 мсек на файл не являются ненормальными для тома NTFS с таким количеством файлов. (На обычном шпиндельном приводе в любом случае нельзя ожидать большего, потому что он находится в том же порядке, что и время поиска головки. С этого момента я предполагаю, что мы имеем дело с оборудованием корпоративного класса, SSD и / или RAID.)

Исходя из моего опыта, вы можете значительно увеличить пропускную способность за счет распараллеливания запросов, т. Е. Использования нескольких потоков и / или процессов. Похоже, что большая часть накладных расходов приходится на поток, система может открыть десять файлов одновременно почти так же быстро, как она может открыть отдельный файл. Я не уверен, почему это так. Возможно, вам придется поэкспериментировать, чтобы найти оптимальный уровень распараллеливания.

Системный администратор также может значительно повысить производительность, скопировав содержимое на новый том, предпочтительно примерно в том же порядке, в котором к ним будет осуществляться доступ. Мне пришлось сделать это недавно, и это сократило время резервного копирования (для тома с примерно 14 миллионами файлов) с 85 часов до 18 часов.

Вы также можете попробовать OpenFileById ( ), который может лучше работать с файлами в больших каталогах, так как он не требует перечисления дерева каталогов. Однако я сам никогда не пробовал, и это может не иметь большого влияния, поскольку каталог, скорее всего, все равно будет кэширован, если вы только что его перечислили.

Вы также можете быстрее перечислить файлы на диске, прочитав их из MFT, хотя это звучит так, как будто это не так. в настоящий момент для вас это узкое место.

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

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

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

Также проверьте наличие антивирусных программ в вашей системе. Некоторые будут замедлять каждый доступ к файлу, сканируя весь файл каждый раз, когда вы пытаетесь получить к нему доступ. Использование Sysinternals Procmon может помочь вам обнаружить такого рода проблемы.

Пытаясь повысить производительность, рекомендуется поставить перед собой цель. Насколько быстро достаточно быстро?

РЕДАКТИРОВАТЬ: Эта часть исходного ответа неприменима, если вы не используете Windows XP или более раннюю версию:

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

NTFS работает медленно с большим количеством файлов. Особенно, если они находятся в одном каталоге. Когда они разделены на отдельные директории и поддиры, доступ происходит быстрее. У меня есть опыт работы со многими файлами, хранящимися на плате видеокамеры (4 камеры), и это было слишком медленно, даже чтобы увидеть количество файлов и размер (Свойства в корневой папке). Интересно, что когда на диске стоит FAT32, то же самое намного шустрее. И все источники говорят, что NTFS быстрее ... Может быть, быстрее для чтения одного файла, но операции с каталогами медленнее.

Зачем нужно столько файлов? Надеюсь, служба индексации каталогов включена.