При развертывании решений на платформе 1С:Предприятие в связке с MS SQL Server одной из ключевых задач системного администратора является правильное конфигурирование параметров файлов баз данных. Стандартные настройки СУБД по умолчанию ориентированы на универсальные сценарии и часто приводят к существенному снижению производительности 1С, регулярным зависаниям («фризам») в моменты интенсивной работы пользователей и избыточной нагрузке на дисковую подсистему.
В этой статье мы подробно разберем, как правильно рассчитать начальный размер файлов данных и журнала транзакций, как настроить безопасный автоприрост, предотвратить фрагментацию виртуальных файлов лога (VLF), а также выясним, актуальна ли рекомендация по форматированию дисков под 64 КБ на современных твердотельных накопителях (SSD и NVMe).
Разберем ситуацию: при создании новой базы данных СУБД предлагает нам установить начальный размер файлов данных (MDF) и журнала транзакций (LDF). Почему не стоит оставлять эти параметры в значениях по умолчанию (например, 8 МБ)?
Когда операционная система выделяет место под файл на диске, она делает это последовательно. Если начальный размер базы данных равен нескольким мегабайтам, то по мере роста базы СУБД будет постоянно запрашивать у ОС новые небольшие блоки. Физически файл базы данных окажется разбросан по всему диску в виде тысяч мелких фрагментов. Это приводит к сильной фрагментации на уровне файловой системы NTFS, что снижает скорость чтения и записи.
Проанализируем оптимальные стартовые значения:
1С:Розница или 1С:Управление нашей фирмой (на 3–5 пользователей и номенклатурой до 10 тысяч позиций), начальный размер файла данных рекомендуется устанавливать в диапазоне от 5 ГБ до 10 ГБ. Даже чистая база «из коробки» после загрузки классификаторов быстро разрастается, поэтому выделение 5 ГБ на старте защитит файл от фрагментации.Выясним, как правильно настроить шаг прироста (Autogrowth). В настройках MS SQL Server прирост можно указать либо в процентах, либо в фиксированных мегабайтах. Установка автоприроста в процентах (например, 10%) — это классический антипаттерн администрирования баз данных.
Рассмотрим, к чему это приводит на практике:
В момент, когда СУБД запрашивает у операционной системы выделение такого объема данных, все операции записи блокируются. Пользователи 1С в этот момент наблюдают глухое зависание программы — те самые «фризы» интерфейса, на которые часто жалуются операторы.
Золотое правило: Настраиваем автоприрост как для файлов данных, так и для файлов логов строго в фиксированных мегабайтах. Оптимальный шаг прироста составляет 512 МБ или 1024 МБ. Для очень мелких баз допускается значение в 200–250 МБ, но не менее, чтобы избежать частых операций расширения файлов.
Разберем природу зависаний при расширении файлов. По умолчанию Windows при выделении нового пространства на диске для безопасности заполняет его нулями (процесс zeroing), затирая старые данные. Пока этот процесс идет, база данных «ждет», и работа 1С приостанавливается.
Чтобы решить эту проблему, включим механизм Мгновенной инициализации файлов (Instant File Initialization — IFI). Он позволяет SQL Server мгновенно забирать место у операционной системы без предварительного зануления. Файлы данных начинают расти моментально, и пользователи не замечают микрофризов.
Выполним настройку IFI по шагам:
secpol.msc и нажимаем Enter).NT Service\MSSQLSERVER).После этого файлы данных (.MDF) будут расширяться мгновенно. Однако помните, что до версии SQL Server 2022 эта технология не работала для файлов журнала транзакций (.LDF).
Проанализируем важное нововведение в версии **SQL Server 2022**. Начиная с этой версии СУБД, механизм мгновенной инициализации файлов (IFI) стал доступен и для журнала транзакций (.LDF). Это позволяет полностью исключить задержки на запись при росте лога.
Но здесь есть строгое техническое ограничение: IFI для логов работает только в том случае, если шаг автоприроста файла .LDF установлен в размере строго до 64 МБ включительно. Если вы установите шаг прироста лога в 128 МБ или 512 МБ, SQL Server 2022 будет вынужден занулять выделяемое пространство по старой схеме.
Поэтому на SQL Server 2022 рекомендуется следующая стратегия:
Выясним, почему опасно настраивать слишком маленький шаг автоприроста лога (например, по 10–50 МБ) на старых версиях SQL Server. Внутренняя структура файла журнала транзакций состоит из множества сегментов — виртуальных лог-файлов (Virtual Log Files — VLF).
Если файл лога прирастает мелкими порциями, количество VLF внутри него начинает исчисляться тысячами. Высокая фрагментация VLF (более 1000 штук) приводит к серьезным проблемам:
INSERT, UPDATE, DELETE), так как СУБД тратит ресурсы на управление огромным списком сегментов лога.Для мониторинга количества VLF в базе данных мы можем выполнить следующий T-SQL запрос в СУБД:
-- Запрос для проверки количества виртуальных лог-файлов (VLF)
SELECT DB_NAME(database_id) AS DatabaseName, COUNT(file_id) AS VLF_Count
FROM sys.dm_db_log_info(DEFAULT)
GROUP BY database_id;
Если полученное значение VLF_Count превышает 1000, рекомендуется провести процедуру сжатия лога (Shrink) до минимального размера во время технологического окна, а затем сразу увеличить его размер вручную до необходимого рабочего объема крупными шагами (например, по 1024 МБ за один раз).
Рассмотрим еще один важный вопрос разметки дисковой подсистемы. При форматировании дисков под базы данных в Windows по умолчанию устанавливается размер кластера NTFS, равный 4 КБ. Инструкции 1С и Microsoft настоятельно рекомендуют использовать размер кластера **64 КБ**.
Актуально ли это для современных твердотельных накопителей (SSD, NVMe)?
Да, эта рекомендация полностью актуальна и сегодня. И вот почему:
Разметка дисков с размером кластера 64 КБ минимизирует накладные расходы процессора на обработку очередей ввода-вывода, исключает проблему избыточного чтения (Split I/O) и значительно ускоряет работу тяжелых отчетов 1С, процедур реиндексации таблиц и создание резервных копий.
Обсуждая оптимизацию основной базы данных 1С, администраторы часто упускают из виду системную базу данных **TempDB**. Именно в ней 1С строит многочисленные временные таблицы для выполнения сложных расчетов, проведения документов и формирования отчетов.
Настроим TempDB по лучшим практикам:
Некоторые специалисты, стремясь сэкономить место на диске, настраивают автоматическое сжатие баз данных (опция Auto-Shrink) или запускают регулярный Shrink файлов по расписанию. Рассмотрим, почему этого делать категорически нельзя.
Процесс сжатия физически перемещает страницы данных из конца файла в его начало, заполняя пустые пространства. При этом нарушается логический порядок страниц, что приводит к **практически 100%-й фрагментации индексов** таблиц 1С. Любые поисковые запросы к СУБД после этого начинают катастрофически тормозить. Базу данных необходимо держать «раздутой» до того естественного объема, который ей реально необходим для пиковых нагрузок (например, для закрытия месяца в 1С).
Подведем итог и составим итоговый чек-лист для создания базы данных 1С на MS SQL Server: