Развертывание такой тяжелой конфигурации, как 1С:ERP Управление предприятием, требует особого внимания к настройкам СУБД, а также изучения практического примера решения проблем быстродействия в ERP. В отличие от небольших баз, ERP активно взаимодействует с временными таблицами, выполняет сложные расчеты и генерирует огромный объем транзакций. В этой статье мы подробно разберем, как оптимизировать Microsoft SQL Server, чтобы обеспечить максимальную производительность и стабильность системы.
Рассмотрим стандартную ситуацию: при создании новой базы SQL Server предлагает настройки по умолчанию (например, 64 Мб), которые совершенно не подходят для корпоративных систем. Давайте проанализируем, почему рекомендации вендора (фирмы 1С) указывают на значение 512 Мб.
Если установить слишком маленький шаг роста, то при активном наполнении базы SQL Server будет вынужден постоянно приостанавливать операции записи для расширения файла. Это приводит к физической фрагментации файла на диске (оценить текущий размер таблиц базы данных можно специализированными обработками). С другой стороны, слишком большой шаг может вызвать длительную задержку при выделении места. Для 1С:ERP на начальном этапе (от 50 пользователей) значение 512 Мб является «золотой серединой».
Важный момент: настройки автоувеличения можно изменять «на лету» без остановки работы пользователей. Если через год база вырастет до нескольких терабайт, шаг увеличения можно будет пересмотреть в сторону увеличения (например, до 1024 Мб или более).
Разберем технологию, которая упоминалась в обсуждении — Instant File Initialization (IFI). По умолчанию, когда SQL Server расширяет файл данных, он заполняет новое пространство нулями, чтобы очистить данные, оставшиеся от удаленных файлов ОС. Это занимает время.
Мы рекомендуем включить IFI, предоставив службе SQL Server право выполнения задач по обслуживанию томов (Volume Maintenance Tasks). Это позволит мгновенно выделять место под файлы .mdf и .ndf. Обратите внимание, что на файлы лога транзакций (.ldf) эта настройка не влияет — они всегда зануляются для обеспечения безопасности и целостности.
Проанализируем работу лога транзакций. Одной из скрытых проблем является фрагментация лога на логическом уровне — возникновение слишком большого количества VLF (Virtual Log Files). Это происходит, если лог растет мелкими порциями (например, по 10% или по 1 Мб).
Последствия избытка VLF:
Shrink и восстановления.Посмотрим на правильный алгоритм настройки: лучше не полагаться на автоувеличение, а сразу задать логу фиксированный размер, который покроет самую ресурсозатратную операцию (например, реиндексацию базы). Оптимально установить фиксированный шаг роста лога в 256 или 512 Мб вместо процентного соотношения, а контролировать объемы дискового пространства поможет SQL Базомер.
Для 1С:ERP база TempDB является критическим узлом. Выясним причину: система постоянно создает временные таблицы для расчетов себестоимости, планирования и формирования отчетов. Если TempDB настроена неправильно, возникают конфликты выделения страниц (контенция).
Разберем по шагам правила настройки TempDB:
TempDB должны иметь строго одинаковый начальный размер и одинаковый шаг автоувеличения. Это заставит SQL Server использовать алгоритм Round-robin для равномерного распределения нагрузки.TempDB на самый быстрый доступный SSD или NVMe накопитель.Стандартные настройки MAXDOP (Maximum Degree of Parallelism) в SQL Server часто вредят логике 1С. Выясним, почему это происходит. Запросы 1С часто бывают очень сложными, и попытка SQL Server распараллелить один такой запрос на 32 ядра может привести к взаимным блокировкам ресурсов процессора.
Для большинства систем 1С рекомендуются следующие параметры:
Рассмотрим ситуацию, когда сервер 1С и SQL Server установлены на одной физической машине. SQL Server по своей природе стремится занять всю доступную память под буферный кэш. Если не установить лимит, он «вытеснит» рабочие процессы rphost, что приведет к их аварийному завершению.
Обязательно настройте параметр Max Server Memory. Мы рекомендуем оставлять операционной системе и процессам 1С не менее 4–8 Гб (а для ERP — лучше 16 Гб и выше, в зависимости от количества пользователей и сложности расчетов).
Проанализируем влияние дисковой подсистемы. Для достижения максимального быстродействия рекомендуется разделять файлы на разные физические диски:
.mdf) — на один массив..ldf) — на другой (самый быстрый на запись SSD).TempDB) — на отдельный накопитель.Важная техническая деталь: При форматировании дисков под SQL Server в Windows необходимо выбирать размер кластера 64 Кб. Это соответствует размеру экстента (8 страниц по 8 Кб), которым оперирует SQL Server, что значительно ускоряет операции ввода-вывода (I/O) и снижает нагрузку на контроллер диска.
Разберем применение специфических флагов, которые помогают оптимизировать работу движка. Рассмотрим примеры наиболее часто используемых:
TempDB, заставляя SQL Server всегда выделять полные экстенты (64 Кб) вместо смешанных.Пример команды для включения флага трассировки (выполняется в SQL Management Studio):
DBCC TRACEON (1118, -1);
DBCC TRACEON (2371, -1);
Посмотрим на важный нюанс при обновлении версии SQL Server. В сообщении на форуме советовали ставить наивысший уровень совместимости. Однако мы рекомендуем проявлять осторожность: новый оптимизатор запросов (например, в SQL 2019/2022) может изменить планы выполнения так, что некоторые тяжелые отчеты ERP станут работать медленнее. После миграции на новую версию SQL Server стоит провести нагрузочное тестирование и, в случае проблем, попробовать вернуть Compatibility Level предыдущей версии.