При развертывании высоконагруженных систем на базе 1С:Предприятие и MS SQL Server одним из самых критичных вопросов является архитектура дисковой подсистемы. Особенно остро этот вопрос встает в среде виртуализации (например, VMware ESXi), где необходимо грамотно распределить нагрузку между имеющимися физическими накопителями разного типа: NVMe, SSD и HDD. Рассмотрим детально, как организовать хранение файлов баз данных, журналов транзакций и рабочих каталогов 1С для обеспечения максимальной производительности.
Рассмотрим типовой сценарий: на физическом сервере установлены две виртуальные машины (ВМ). Первая ВМ выполняет роль сервера приложений 1С, вторая — сервера баз данных MS SQL Server 2019. В распоряжении администратора имеется высокоскоростной диск NVMe объемом 1.7 Тб и набор SSD/HDD дисков. Проанализируем, как распределить данные наиболее эффективно.
Основная цель распределения — минимизация задержек (latency) и исключение узких мест при одновременном чтении и записи. Для этого мы разделим типы данных по характеру нагрузки, предварительно проведя замер производительности контура 1С и поиск узких мест:
Оптимальным решением будет использование NVMe для наиболее «горячих» данных. Разберем итоговый вариант конфигурации:
TempDB, журналы транзакций (.ldf) всех рабочих баз и рабочий каталог сервера 1С (srvinfo)..mdf) могут располагаться на SSD. Если бюджет ограничен и используется RAID 10 из производительных HDD, базы можно разместить на нем, при условии, что журналы транзакций и TempDB вынесены на NVMe.Выясним причину, по которой стандартные настройки Windows не подходят для SQL Server. По умолчанию файловая система NTFS форматируется с размером кластера 4 КБ. Однако для MS SQL Server стандартом де-факто является размер кластера 64 КБ.
Рассмотрим подробнее преимущества этого подхода. SQL Server читает и записывает данные блоками (экстентами) по 64 КБ (8 страниц по 8 КБ). Если размер кластера файловой системы равен 4 КБ, для записи одного экстента операционной системе приходится выполнять 16 операций ввода-вывода. При размере кластера 64 КБ выполняется всего одна операция. Это существенно снижает IOPS и нагрузку на процессор при массивных сканированиях таблиц, типичных для отчетов 1С.
Важно: Форматируйте разделы под базы данных и логи именно с размером кластера 64 КБ перед переносом файлов.
Проанализируем структуру файлов TempDB. Просто вынести ее на NVMe недостаточно. Для уменьшения конкуренции за ресурсы внутри SQL Server необходимо создать несколько файлов данных TempDB равного размера.
Рекомендуется придерживаться следующего правила: количество файлов данных должно соответствовать количеству логических ядер процессора, выделенных виртуальной машине (но не более 8 файлов на старте). Если после настройки наблюдается конкуренция за страницы распределения (PFS, GAM), количество файлов можно увеличивать шагами по 4.
Следующий важный шаг — настройка Мгновенной инициализации файлов (Instant File Initialization). Разберем, как это работает. При создании или расширении файла базы данных SQL Server обычно зануляет выделенное пространство, что на больших объемах занимает много времени и нагружает диск. Включение этой опции позволяет SQL Server просто запрашивать место у ОС без зануления.
Чтобы активировать этот механизм, выполним следующие шаги:
Это критично для баз 1С, которые часто растут динамически, так как исключает «зависания» системы в момент расширения файла .mdf.
Поскольку наши системы работают внутри ESXi, необходимо правильно настроить виртуальное оборудование. Посмотрим на рекомендации для достижения максимальной производительности:
Рассмотрим ситуацию с памятью. SQL Server по умолчанию стремится занять всю доступную оперативную память. В виртуальной среде это может привести к «свопингу» на уровне гипервизора, что катастрофически снижает скорость работы. Необходимо жестко ограничить параметр Max Server Memory в настройках SQL Server, оставив операционной системе 2–4 ГБ свободными.
Также важно включить политику Lock Pages in Memory (Блокировка страниц в памяти) для учетной записи SQL Server, чтобы Windows не могла вытеснить страницы памяти SQL в файл подкачки.
Для 1С крайне критична настройка параллелизма. Проанализируем параметр MAXDOP (Max Degree of Parallelism). Если оставить его в значении 0 (использовать все ядра), один «тяжелый» запрос пользователя 1С может парализовать работу всей системы. Рекомендуется устанавливать значение MAXDOP от 1 до 4 в зависимости от общего количества ядер, чтобы сбалансировать нагрузку.
Вынос рабочего каталога 1С на быстрый NVMe — правильное решение, предложенное в обсуждении. Выясним причину: в каталоге srvinfo хранится журнал регистрации. В активных базах он генерирует множество мелких операций записи. Если диск будет медленным, пользователи могут ощущать задержки при проведении документов. Однако помните, что на NVMe место ограничено, поэтому настройте регулярное сокращение журнала регистрации или его архивацию, чтобы он не переполнил скоростной накопитель.
Подводя итог, наиболее сбалансированная схема выглядит так: системные диски на HDD/SSD, файлы данных 1С на SSD (с кластером 64 КБ), а TempDB, логи транзакций и временные файлы 1С — на NVMe. Такая конфигурация позволит 1С работать максимально плавно даже при интенсивной нагрузке.