Назад | Перейти на главную страницу

Как настроить Windows Server 2012 R2 для обработки файловой структуры NTFS с 50 миллионами файлов?

У меня есть утилита для разработчиков, которую я буду использовать для создания 50 миллионов файлов. Структура каталогов включает четыре уровня. Верхний уровень содержит 16 каталогов (2000-2016 годы), следующий уровень - месяцы (1-12), следующий уровень - дни (1 - 31) и, наконец, - файлы xml (до 85k каждый). Последний каталог может содержать более 3000 файлов (я не проводил математических расчетов, чтобы выяснить, как 50 миллионов поместятся в эту структуру каталогов).

В настоящее время я запускаю эту утилиту, и у меня около 1/3 завершения (дней на выполнение). Как я и опасался, обход любой части дерева каталогов - болезненный опыт. Занимает несколько секунд только в проводнике. Это с оборудованием серверного уровня. SAS 7200RPM (я знаю, что в наши дни это не так быстро) 12 терабайт Raid 5 или 10, выделенные 4 процессорам xeon 3,4 ГГц.

Как увеличить способность Windows Server 2012 R2 кэшировать дескрипторы файлов в памяти? У меня не запущена служба NFS.


M:\>defrag /a /v /h m:
Microsoft Drive Optimizer
Copyright (c) 2013 Microsoft Corp.

Invoking slab consolidation on DB MDF (M:)...


The operation completed successfully.

Post Defragmentation Report:

    Volume Information:
            Volume size                 = 12.99 TB
            Cluster size                = 64 KB
            Used space                  = 1.55 TB
            Free space                  = 11.44 TB

    Slab Consolidation:
            Space efficiency            = 100%
            Potential purgable slabs    = 1

M:\>

C:\Windows\system32>fsutil fsinfo ntfsinfo m:
NTFS Volume Serial Number :       0x9c60357c60355de8
NTFS Version   :                  3.1
LFS Version    :                  2.0
Number Sectors :                  0x000000067ffbefff
Total Clusters :                  0x000000000cfff7df
Free Clusters  :                  0x000000000b6bcb45
Total Reserved :                  0x0000000000000004
Bytes Per Sector  :               512
Bytes Per Physical Sector :       4096
Bytes Per Cluster :               65536
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length :           0x0000000320900000
Mft Start Lcn  :                  0x000000000000c000
Mft2 Start Lcn :                  0x0000000000000001
Mft Zone Start :                  0x00000000018f8780
Mft Zone End   :                  0x00000000018f9420
Resource Manager Identifier :     A47067E0-6356-11E6-8

C:\Windows\system32>

Rammap

Сведения о метафайле: Всего = 2 882 220 К, Актив = 2 736 688 К, Ожидание = 143 968 К, Изменено = 852 К, Изменено без записи = 712 К.

Что еще было бы интересно на этой странице?

На данный момент серверу выделено 16 ГБ памяти. Я мог бы попросить гораздо больше.


C:\Windows\system32>fsutil.exe 8dot3name query m:
The volume state is: 1 (8dot3 name creation is disabled).
The registry state is: 2 (Per volume setting - the default).

Based on the above two settings, 8dot3 name creation is disabled on m:

C:\Windows\system32>

Contig v1.8 - Contig
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals

m:\$Mft is in 80 fragments
m:\$Mft::$BITMAP is in 32 fragments

Summary:
     Number of files processed:      2
     Number unsuccessfully procesed: 0
     Average fragmentation       : 56 frags/file

NtfsInfo v1.2 - NTFS Information Dump
Copyright (C) 2005-2016 Mark Russinovich
Sysinternals - www.sysinternals.com


Volume Size
-----------
Volume size            : 13631357 MB
Total sectors          : 27917021183
Total clusters         : 218101727
Free clusters          : 184577826
Free space             : 11536114 MB (84% of drive)

Allocation Size
----------------
Bytes per sector       : 512
Bytes per cluster      : 65536
Bytes per MFT record   : 0
Clusters per MFT record: 0

MFT Information
---------------
MFT size               : 16210 MB (0% of drive)
MFT start cluster      : 49152
MFT zone clusters      : 33255616 - 33258848
MFT zone size          : 202 MB (0% of drive)
MFT mirror start       : 1

Meta-Data files
---------------

В настоящее время у вас есть MFT размером 0x320900000 = 13 431 209 984 байта = 12 ГиБ, из которых только 2 ГБ находится в памяти. Больше оперативной памяти позволит вам иметь больше этого в памяти, если вы хотите кэшировать больше «файловых дескрипторов», то есть метаданных файловой системы.

Независимо от того, какую файловую систему вы используете, метаданные будут, и в зависимости от моделей использования файловой системы вам может быть лучше инвестировать в больше оперативной памяти И / ИЛИ более быстрое хранение. Если объем метафайловой информации нереально хранить в ОЗУ, и ваши шаблоны использования файлов обычно имеют дело с новыми файлами вместо многократного использования меньшего подмножества файлов, тогда более быстрое хранилище, такое как массивы raid 10 с множеством зеркальных пар для чередования от более быстрых SSD и / или дисков SAS 15 000 об / мин может потребоваться для ограничения времени поиска и увеличения количества доступных операций ввода-вывода в секунду, которые может обрабатывать хранилище.

Имейте в виду, что настройки диспетчера памяти Windows по умолчанию могут не применяться к вашей ситуации, и вам может потребоваться настроить некоторые параметры, особенно если вы не планируете иметь достаточно оперативной памяти для размещения всего MFT в ОЗУ в дополнение к тому, что остальная часть система требует. Я заметил, что почти все ваши данные метафайлов помечены как активная память, что означает, что системе кэширования Windows не разрешено удалять их из ОЗУ, когда они не используются. Мой сценарий PowerShell на Использование ОЗУ метафайлами Windows Server 2008 R2 может использоваться (даже на Server 2008 до 2012R2, а я ожидаю 2016) для установки минимального и максимального количества метафайловой памяти, помеченной как активная, и перевода остальных в режим ожидания. Это позволяет системе кэширования лучше определять приоритеты того, что находится в ОЗУ.

Изменить: хотя я не знаком с jmeter, похоже, что шаблон использования файловой системы будет

  1. напишите их все последовательно.
  2. прочтите их как можно быстрее, в основном последовательно
  3. прочитать их все второй раз в частично случайном порядке (поскольку каждый поток конкурирует за чтение группы файлов, которую он хочет), чтобы отправить их по сети

С такой схемой использования, чтобы увидеть разумную выгоду от добавления НАМНОГО ОЗУ, вам нужно будет добавить достаточно, чтобы уместить весь MFT в ОЗУ. Это вообще пустая трата денег. Когда было бы более рентабельно добавить немного больше ОЗУ и обновить хранилище, чтобы значительно улучшить IOP. Это должно быть быстрее, чем хранение медленного дискового массива raid5 со скоростью вращения 7.2K об / мин или даже raid10, сделанного только с 4 дисками с колоссальным объемом оперативной памяти, поскольку метаданные - не единственные данные, которые читаются / записываются из / в хранилище. Видеть этот калькулятор в качестве инструмента оценки ожидаемой производительности операций ввода-вывода в секунду и того, как разное количество дисков и уровни рейдов влияют на производительность.

В приведенном выше случае единственный способ добавить еще больше оперативной памяти может быть быстрее, чем использование системы с более быстрым хранилищем, - это если вы добавите достаточно оперативной памяти, чтобы все данные, включая содержимое файла, также были в оперативной памяти. Вот почему некоторые системы баз данных заявляют, что они работают «на 100% в памяти», чтобы не было задержек в системе хранения.