Как мне настроить 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 K, активный = 2,736,688 K, режим ожидания = 143,968 K, измененный = 852 K, Modified no write = 712 K.
Что еще может быть интересно на этой странице?
В это время серверу выделено 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 Гигабайта. Больше оперативной памяти позволит вам иметь больше оперативной памяти, если вы хотите кэшировать больше метаданных "файловых ручек", так же известных как и метаданные файловой системы
Независимо от того, какую файловую систему вы используете, метаданные будут существовать, и в зависимости от шаблонов использования файловой системы вам, возможно, лучше инвестировать в больше тарана И/Или более быстрое хранение. Если объем метафайловой информации нереален для хранения всего этого в оперативной памяти и ваши шаблоны использования файлов обычно имеют дело с новыми файлами вместо того, чтобы многократно использовать меньшее подмножество файлов, то для ограничения времени поиска и увеличения объема доступных IOP-ов, с которыми может справиться хранилище, может потребоваться более быстрое хранение, например, 10 массивов рейда с большим количеством зеркальных пар для чередования, сделанных с более быстрых SSD и/или SAS дисков 15K RPM, которые могут быть использованы.
Имейте в виду, что настройки по умолчанию менеджера памяти Windows могут быть неприменимы к вашей ситуации, и вам может понадобиться подкорректировать некоторые настройки, особенно если вы не планируете иметь достаточно оперативной памяти, чтобы вместить всю MFT в оперативную память в дополнение к тому, что требуется остальной части системы. Я заметил, что почти все данные вашего метафайла помечены как активная память, что означает, что системе кэширования Windows не разрешается выбрасывать их из оперативной памяти, когда они не используются. Мой сценарий powershell на Windows Server 2008 R2 Metafile RAM Usage можно использовать (даже на сервере с 2008 по 2012R2, и я ожидаю 2016), чтобы установить минимум и максимум на объем памяти метафайлов, помеченной как активная, и заставляет остальных быть наготове. Это позволяет системе кэширования лучше расставлять приоритеты того, что находится в оперативной памяти.
Edit: Хотя я не знаком с jmeter, похоже, что шаблон использования файловой системы будет
- записывать их все последовательно.
- прочитайте их все так быстро, как это возможно в основном последовательным способом
- прочитайте их все второй раз по частично случайному шаблону (так как каждый поток конкурирует за чтение группы файлов, которые он хочет), чтобы послать их по сети
С такой схемой использования, чтобы увидеть разумную выгоду от добавления LOT больше барабана, вам нужно будет добавить достаточно, чтобы вместить всю MFT в оперативную память. Обычно это пустая трата денег. Когда было бы более выгодно добавить немного больше оперативной памяти, а также обновить хранилище для значительного улучшения IOP-ов. Это должно быть быстрее, чем медленный 7.2K rpm дисковый raid5-массив, или даже raid10, сделанный только с 4 дисками с колоссальным количеством ram, так как метаданные - это не единственные данные, которые читаются/записываются из/в хранилище. Смотрите этот калькулятор как инструмент оценки ожидаемой производительности IOPs, и как разное количество дисков и уровни рейда влияют на производительность.
В описанном выше случае, единственный способ, при котором добавление еще большего количества баранов может быть быстрее, чем использование системы с более быстрым хранением, это если вы добавите достаточно барабанчика, чтобы все данные, включая содержимое файлов, также находились в барабанчике. Поэтому некоторые системы БД рекламируют, что они работают "на 100% в памяти", так что задержек в системе хранения нет.
.