← На главную

Перевод дисковой подсистемы сервера СУБД на твердотельные накопители корпоративного класса — один из самых действенных способов устранить задержки ввода-вывода в высоконагруженных базах 1С. Однако слепая установка накопителя корпоративного уровня, такого как Intel SSD DC P3700 (интерфейс PCIe NVMe), без понимания архитектуры работы СУБД часто приводит к неоправданным затратам. Разберем практический опыт эксплуатации таких накопителей, выясним распределение нагрузки между файлами баз данных и определим оптимальные варианты архитектуры дисковой подсистемы.

Анализ профиля дисковой нагрузки в связке 1С и MS SQL Server

Прежде чем инвестировать в дорогостоящие NVMe-диски, проанализируем, куда именно приходится основной поток дисковых операций в базах 1С. В типовых сценариях учетных систем интенсивность обращений распределяется неравномерно:

1. Служебная база tempdb: принимает на себя до 30–50% всего дискового трафика сервера. Механизмы 1С активно оперируют временными таблицами при проведении документов, формировании сложных отчетов и расчете итогов. Задержки на этом накопителе напрямую вызывают ожидания на уровне СУБД.
2. Журнал транзакций (.ldf): выполняет строго последовательную запись (операция WRITELOG). Здесь критична не пропускная способность (гигабайты в секунду), а минимальная задержка отклика (latency), измеряемая в долях миллисекунды.
3. Основные файлы данных (.mdf / .ndf): чтение из них активно кэшируется в оперативной памяти (Buffer Pool). Если сервер располагает достаточным объемом RAM, нагрузка на чтение данных существенно снижается, а запись сбрасывается пакетами («грязные» страницы).

Практика показывает, что размещение всей базы целиком на одном дорогом NVMe-накопителе часто оказывается избыточным. Наибольшую отдачу дает гибридный подход: размещение базы tempdb и критически важных таблиц на NVMe, в то время как основной массив данных может безопасно располагаться на отказоустойчивом RAID-массиве из SAS или SATA SSD.

Оптимизация и вынос базы tempdb

Рассмотрим реальный пример внедрения: перенос базы tempdb с классического дискового массива на накопитель Intel DC P3700 позволил сократить среднее время ожидания чтения и записи с 250 мс до 1.3–8 мс. Для получения максимальной отдачи от быстрого диска обязательно выполним комплексную настройку параметров СУБД:

1. Множественные файлы данных: разделим tempdb на несколько файлов данных одинакового размера (рекомендуется создавать от 4 до 8 файлов, ориентируясь на количество физических ядер процессора). Это устраняет внутреннюю конкуренцию за системные страницы распределения (PFS и SGAM).
2. Одинаковый авторост: зададим фиксированный шаг автороста в мегабайтах (а не в процентах) одинаковым для всех файлов группы, чтобы СУБД распределяла запись методом пропорционального заполнения (Proportional Fill).
3. Мгновенная инициализация файлов (IFI): предоставим сервисной учетной записи MS SQL Server право локальной политики безопасности «Выполнение задач по обслуживанию томов» (SE_MANAGE_VOLUME_NAME). Это исключит трату времени на обнуление секторов нулями при пересоздании tempdb после перезагрузки сервера.
4. Флаги трассировки: для версий MS SQL Server 2014 и старше включим флаги запуска -T1117 (одновременный рост всех файлов группы) и -T1118 (выделение только полных экстентов). В версиях 2016 и новее данное поведение активно по умолчанию.

Отдельно отметим идею размещения tempdb на программном RAM-диске в оперативной памяти. Данная схема допустима исключительно для tempdb, так как ее структура пересоздается при каждом старте службы. Размещать на RAM-диске рабочие базы категорически запрещено: при любом аварийном отключении питания данные будут безвозвратно утеряны.

Надежность, организация RAID и защита от сбоев

Накопитель Intel SSD DC P3700 относится к корпоративной линейке с высоким ресурсом перезаписи (High Endurance, порядка 10-17 DWPD), однако использование одиночного диска без резервирования создает критическую точку отказа для бизнеса с режимом работы 24/7. Разберем способы организации отказоустойчивости:

1. Аппаратные ограничения NVMe: классические RAID-контроллеры с портами SAS/SATA не работают с платами PCIe NVMe напрямую. Попытка собрать программный RAID средствами чипсета или базовых утилит Windows может существенно нагружать ядра центрального процессора (до 50–70% утилизации CPU при операциях ввода-вывода).
2. Технология Intel VROC (Virtual RAID on CPU): на серверных платформах с процессорами Intel Xeon Scalable доступна организация аппаратного зеркала (RAID 1) для NVMe-накопителей без промежуточных контроллеров и задержек, с прямым доступом к шине PCIe через процессор.
3. Резервирование на уровне СУБД: наиболее надежный корпоративный подход — использование двух независимых серверов с быстрыми накопителями, объединенных в синхронную группу доступности (Always On Availability Groups) или зеркалирование (Database Mirroring). В случае физического выхода из строя диска на основном узле СУБД мгновенно переключает нагрузку на реплику без прерывания рабочих процессов 1С.

Особенности установки ОС и виртуализации

Проанализируем технические требования при интеграции PCIe NVMe в существующую инфраструктуру:

1. Установка операционной системы: если планируется использовать диск как загрузочный, материнская плата сервера обязана поддерживать UEFI версии не ниже 2.3.1. Однако размещать системный раздел ОС на таком диске экономически нецелесообразно: операционная система не создает профильной нагрузки, и под нее достаточно выделить отдельное зеркало из недорогих SATA SSD.
2. Виртуализация (VMware vSphere / Hyper-V): при работе СУБД внутри виртуальной машины рекомендуется использовать контроллер типа Virtual NVMe (vNVMe) вместо устаревших PVSCSI. Это сохраняет поддержку моментальных снимков и механизмов миграции (vMotion) при минимальных накладных расходах процессора на эмуляцию дисковых очередей. Прямой проброс устройства (PCIe Passthrough) дает предельную производительность, но лишает виртуальную машину гибкости управления гипервизором.

Итоговые рекомендации по модернизации

Подведем итог: применение накопителей уровня Intel DC P3700 оправдано и показывает великолепные результаты в сценариях, где зафиксированы реальные дисковые задержки. Оптимальная конфигурация под сервер 1С среднего и крупного масштаба выглядит следующим образом:

1. Операционная система развертывается на отдельном RAID 1 из надежных SAS/SATA накопителей.
2. База tempdb и высоконагруженные таблицы переносятся на PCIe NVMe-накопитель корпоративного уровня.
3. Файлы рабочих баз и журналы транзакций размещаются на отказоустойчивом дисковом пуле (RAID 10) с регулярным созданием резервных копий и выгрузкой архивов на внешнее хранилище.
4. Сервер обеспечивается высокочастотными ядрами процессора (от 3.2 ГГц и выше), так как платформа 1С крайне чувствительна к однопоточной производительности CPU при формировании запросов к СУБД.