Windows Server 2003 SP2 LUN, смонтированный из SAN Миллионы небольших файлов в сотнях тысяч каталогов (всего 100 ГБ) NTFS с размером кластера 4 КБ
При первоначальном сканировании файлов для резервного копирования или архивирования доступ обычных пользователей к файлам на этом диске сильно замедляется.
Специалисты по SAN и сетям не проявляют аномальной активности при начальных исследованиях, но более глубокие исследования продолжаются. Подозревается какая-то проблема на уровне сервера с NTFS или Windows.
Учитывая, что почти все файлы имеют размер <10 КБ, поэтому они помещаются в 1-3 кластера, я не подозреваю, что регулярная фрагментация является проблемой, но, возможно, фрагментация MFT может быть проблемой. Учитывая, что резервное копирование и очистка вызывают нарушение работы пользователя даже в нерабочее время, я не решаюсь использовать дефрагментацию Windows для анализа моей фрагментации, и меня действительно волнует только фрагментация MFT. Кто-нибудь мог понять это быстрее, чем полный анализ диска?
Хорошие сторонние программы дефрагментации тоже не исключены, если у кого-то есть рекомендации. Наш анализ не мешает пользователям больше беспокоить нас.
Мы также рассматриваем возможность добавления ключа reg для NtfsDisableLastAccessUpdate. Кто-нибудь нашел, что это действительно большое улучшение, а не просто незначительное изменение?
Есть ли какие-нибудь хорошие инструменты для измерения блокировок файлов / конфликтов доступа к загруженному диску? Инструменты графического интерфейса пользователя от sysinternals, такие как procmon, больше не масштабируются на этом уровне.
Когда вы создаете резервную копию такого тома, вы серьезно загружаете базовое хранилище. Когда вы начинаете читать миллионы маленьких файлов, разбросанных по файловой системе, ограничивающим фактором будет количество операций ввода-вывода в секунду при произвольном чтении, которое могут предоставить базовые диски в вашей SAN. Сама SAN может вообще не перегружаться, но том, с которого вы читаете, получит удар, и любой другой процесс, который пытается сделать что-либо еще в то же время, пострадает, если вы не уменьшите активность резервного копирования.
Следует обратить внимание на глубину очереди на этом томе. Если его пик значительно превышает количество дисков, на которых выполняется резервное копирование тома, значит, вы достигли предела IOPS. Perfmon даст вам представление, но лучшие данные будут получены из собственной аналитики Storage Array, если это возможно. Я серьезно сомневаюсь, что ваша проблема связана с блокировкой файлов. Специалисты по хранилищу должны посмотреть на количество операций ввода-вывода в секунду на дисках в пакете RAID, из которого разделен ваш том, я подозреваю, что эти диски производят более ~ 150 операций ввода-вывода в секунду каждый (выше, если они 15 КБ, ниже, если они 7,2 КБ). . Если у вас есть 6-дисковая группа RAID 10, на которой размещен этот том, то он будет работать со скоростью не намного лучше, чем 10 мегабайт в секунду, если это действительно резервное копирование миллионов файлов размером 10 КБ и очень мало, что намного больше.
NtfsDisableLastAccessUpdate поможет в вашем случае - он сбрасывает набор операций ввода-вывода в секунду для каждого действия с файлом и, в частности, позволяет избежать пары дополнительных операций чтения и записи, связанных с каждым файлом. Учитывая, что у вас есть миллионы и что ваши файлы или настолько малы, что должна быть значительная победа, это может быть до 50% выигрыша. Тем не менее, наиболее вероятный эффект, который вы увидите, заключается в том, что ваше резервное копирование ускорится, но все равно будет достигать предела IOP.
Вы также должны учитывать выравнивание раздела диска если это еще не было сделано. В таком случае (много небольших чтений) это не такая большая победа, как для других шаблонов ввода-вывода, вероятно, около 10% при условии, что размер полосы RAID составляет 128 КБ, а среднее чтение составляет около 10 КБ, но может стоит затраченных усилий. Это потребует резервного копирования всего тома, его повторного разбиения и переформатирования, а затем восстановления данных, так что это нетривиальное упражнение.
Запуск программы дефрагментации диска в режиме анализа - это единственный известный мне способ узнать, сколько у вас фрагментов MFT.
Если громкость используется 24 x 7, вы, вероятно, застряли, «беспокоя» пользователей. Если нет, запланируйте выполнение команды «defrag -a -v C:» в нерабочее время с перенаправлением ее вывода в файл. Это даст вам вывод команды без необходимости бодрствовать, чтобы запустить ее в 4 утра в воскресенье. > улыбка <
Я не могу дать вам статистику re: "NtfsDisableLastAccessUpdate", но я бы определенно установил ее, если вам не нужно сохранять время последнего доступа. (Я бы использовал команду «fsutil behavior set disablelastaccess 1», а не задавал ее в реестре. Вам также необходимо перезагрузиться, чтобы изменения вступили в силу.)
Вы также можете подумать об отключении создания имени файла 8dot3, если оно вам тоже не нужно. Сделайте это, особенно если у вас есть большое количество файлов в одном каталоге. (Хотя отключение этого параметра не избавит от уже существующих имен 8dot3 ...)
Сравнение вывода «fsutil fsinfo statistics» на рассматриваемом томе до / после этого медленного «начального сканирования» может рассказать вам кое-что о том, что происходит, хотя я думаю, что это просто покажет вам, что происходит ужасное количество чтений метаданных .
Достаточно ли у вас места в сети SAN для восстановления всего содержимого тома на новый LUN, настроенный аналогично (с учетом его свойств SAN - уровень RAID и т. Д.), Что и рабочий LUN? Было бы интересно посмотреть, как новая файловая система NTFS с отключенным с самого начала созданием имени 8dot3 и, возможно, зона MFT другого размера ведет себя по сравнению с производственным LUN. (Также не составит большого труда организовать миграцию путем копирования измененных файлов с рабочего LUN на этот промежуточный LUN, если промежуточный LUN работает лучше.)
Я обнаружил, что замедление происходило с запуском десятков тысяч файлов с теми же 5 буквами в качестве префикса. Моя теория заключается в том, что деревья NTFS MFT B + в этом случае создаются слишком глубокими и несбалансированными. Восстановление файлов на новый диск не повлекло за собой повторение проблемы, поэтому я подозреваю, что это каким-то образом правильно сбалансировано при новом создании с файлами все подряд, чем когда файлы создаются случайным образом (иногда один из этих файлов префиксов, а иногда нет) на уже фрагментированный диск.
Мы планируем рандомизировать имена, а также исследовать возможность отключения имен 8dot3 в будущем.