Низкая производительность на NTFS-диске с большим количеством файлов

Я смотрю на эту установку:

Windows Server 2012
Диск NTFS 1 ТБ, кластеры 4 КБ, заполнение ~ 90%
~ 10 млн файлов в 10000 папок = ~ 1000 файлов в папке
Файлы в основном небольшие, <50 КБ
Виртуальный диск, размещенный на дисковом массиве

Когда приложение обращается к файлам, хранящимся в случайных папках, чтение каждого файла занимает 60-100 мс. С тестовым инструментом кажется, что при открытии файла возникает задержка. Тогда чтение данных занимает лишь часть времени.

В итоге это означает, что чтение 50 файлов может занять 3-4 секунды, что намного больше, чем ожидалось. Запись выполняется партиями, поэтому производительность здесь не проблема.

Я уже последовал совету по SO и SF, чтобы получить эти цифры.

Использование папок для уменьшения количества файлов в папке (Хранение миллиона изображений в файловой системе)
Бегать contig для дефрагментации папок и файлов (https://stackoverflow.com/a/291292/1059776)
8.3 имена и время последнего доступа отключены (Настройка файловой системы NTFS для повышения производительности)

Что делать со временем чтения?

Считайте, что 60-100 мс на файл в порядке (это не так, не так ли?)
Есть идеи, как можно улучшить настройку?
Существуют ли инструменты мониторинга низкого уровня, которые могут сказать, на что именно тратится время?

ОБНОВИТЬ

Как упоминалось в комментариях, в системе работает Symantec Endpoint Protection. Однако его отключение не влияет на время чтения.
PerfMon измеряет 10-20 мс на чтение. Это будет означать, что любое чтение файла требует ~ 6 операций чтения ввода-вывода, верно? Будет ли это поиском MFT и проверкой ACL?
MFT имеет размер ~ 8,5 ГБ, что больше, чем основная память.

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

Сервер показал 2 ГБ памяти, доступной как в диспетчере задач, так и в RamMap. Так что либо Windows решила, что доступной памяти недостаточно для хранения значимой части данных метафайлов. Или какое-то внутреннее ограничение не позволяет использовать последний бит памяти для данных метафайла.
После обновления диспетчер задач RAM не показывал больше используемой памяти. Однако RamMap сообщил, что несколько ГБ данных метафайлов хранятся в качестве резервных данных. Судя по всему, данные в режиме ожидания могут иметь существенное влияние.

Инструменты, используемые для анализа:

fsutil fsinfo ntfsinfo driveletter: чтобы показать размер NTFS MFT (или NTFSInfo)
RamMap чтобы показать распределение памяти
Монитор процесса чтобы показать, что каждому чтению файла предшествуют примерно 4 операции чтения с диска: \ $ Mft и диска: \ $ Directory. Хотя я не смог найти точное определение $ Directory, это похоже, связано с MFT также.