Оптимизация MS SQL Server для 1С 8.3: пошаговая настройка

MS SQL Server из коробки работает с настройками, рассчитанными на универсальное применение. Для 1С:Предприятие 8.3 эти настройки не подходят. SQL Server забирает всю доступную память, tempdb лежит на одном файле, параллельные планы выполнения тормозят OLTP-запросы 1С. Результат — медленное проведение документов, зависания при закрытии месяца, жалобы пользователей.

Оптимизация SQL Server для 1С 8.3 — это 8 конкретных настроек, которые ускоряют работу базы в 2-5 раз без замены оборудования. Каждая настройка занимает 5-10 минут. Весь процесс — 1-2 часа с перезагрузкой. В этой статье: команды T-SQL, формулы расчёта, типичные ошибки и готовые рекомендации для серверов с 10-200 пользователями 1С.

Статья для администраторов, которые уже установили SQL Server и настроили кластер серверов 1С. Если вы выбираете между SQL Server и PostgreSQL — начните со сравнения СУБД для 1С. Если нужна помощь с выбором редакции SQL Server — смотрите какой SQL Server выбрать для 1С.

Что потребуется

Перед началом оптимизации подготовьте доступы и инструменты. Все команды выполняются в SQL Server Management Studio (SSMS) или через sqlcmd.

Перед внесением изменений сделайте резервную копию баз и зафиксируйте текущие настройки. Выполните в SSMS:

-- Сохранить текущие настройки перед оптимизацией
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

SELECT name, value_in_use
FROM sys.configurations
WHERE name IN (
    'max server memory (MB)',
    'max degree of parallelism',
    'cost threshold for parallelism',
    'optimize for ad hoc workloads'
)
ORDER BY name;

Шаг 1 — Ограничить память SQL Server

По умолчанию SQL Server использует всю доступную оперативную память. На выделенном SQL-сервере это допустимо. На сервере, где работает ещё и служба 1С (ragent, rmngr, rphost) — это проблема. SQL Server забирает 120 из 128 ГБ, рабочим процессам 1С не хватает памяти, пользователи получают зависания и ошибки.

Формула расчёта max server memory:

max server memory = Общая RAM - 4 ГБ (ОС) - 2 ГБ × количество rphost

Пример для сервера 128 ГБ с 8 рабочими процессами 1С:

128 ГБ - 4 ГБ (ОС) - 16 ГБ (8 × 2 ГБ на rphost) = 108 ГБ → max server memory = 108 000 МБ

Для серверов с разным объёмом RAM:

Применить настройку:

-- Ограничить память SQL Server (пример для 128 ГБ сервера)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'max server memory (MB)', 108000;
RECONFIGURE;

-- Проверить
SELECT name, value_in_use
FROM sys.configurations
WHERE name = 'max server memory (MB)';

Настройка применяется мгновенно без перезагрузки SQL Server. Если SQL Server уже занял больше памяти, чем новый лимит — он постепенно освободит излишки в течение нескольких минут.

Шаг 2 — Настроить tempdb

tempdb — системная база данных, которую SQL Server использует для временных таблиц, сортировок, промежуточных результатов запросов. 1С:Предприятие 8.3 активно использует временные таблицы — практически каждый запрос к базе создаёт и удаляет временные объекты в tempdb. Неправильная настройка tempdb — одна из главных причин медленной работы 1С.

Три правила настройки tempdb для 1С:

• Отдельный NVMe-диск. Перенесите файлы tempdb на выделенный NVMe. Если NVMe нет — хотя бы на отдельный SSD, не тот, где лежат пользовательские базы. tempdb генерирует интенсивный случайный I/O — на общем диске это тормозит всё остальное.
• Количество файлов = число ядер (но не более 8). Несколько файлов tempdb снимают блокировку на системных страницах (PFS, GAM, SGAM contention). Для сервера с 16 ядрами — 8 файлов. Для 4-ядерного — 4 файла. Все файлы одинакового размера.
• Предварительный размер и autogrowth. Задайте начальный размер каждого файла 1-4 ГБ (зависит от нагрузки). Autogrowth — 512 МБ. Маленький autogrowth (10%) вызывает частые расширения и фрагментацию.

-- Узнать текущее расположение файлов tempdb
SELECT name, physical_name, size * 8 / 1024 AS size_mb
FROM sys.master_files
WHERE database_id = DB_ID('tempdb');

-- Перенести основной файл данных tempdb на отдельный диск
ALTER DATABASE tempdb MODIFY FILE (
    NAME = tempdev,
    FILENAME = 'T:\tempdb\tempdev.mdf',
    SIZE = 4096MB,
    FILEGROWTH = 512MB
);

-- Перенести лог tempdb
ALTER DATABASE tempdb MODIFY FILE (
    NAME = templog,
    FILENAME = 'T:\tempdb\templog.ldf',
    SIZE = 2048MB,
    FILEGROWTH = 512MB
);

-- Добавить файлы tempdb (пример для 8 файлов)
-- Файлы 2-8 (tempdev уже существует как первый)
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev2, FILENAME = 'T:\tempdb\tempdev2.ndf',
    SIZE = 4096MB, FILEGROWTH = 512MB
);
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev3, FILENAME = 'T:\tempdb\tempdev3.ndf',
    SIZE = 4096MB, FILEGROWTH = 512MB
);
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev4, FILENAME = 'T:\tempdb\tempdev4.ndf',
    SIZE = 4096MB, FILEGROWTH = 512MB
);
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev5, FILENAME = 'T:\tempdb\tempdev5.ndf',
    SIZE = 4096MB, FILEGROWTH = 512MB
);
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev6, FILENAME = 'T:\tempdb\tempdev6.ndf',
    SIZE = 4096MB, FILEGROWTH = 512MB
);
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev7, FILENAME = 'T:\tempdb\tempdev7.ndf',
    SIZE = 4096MB, FILEGROWTH = 512MB
);
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev8, FILENAME = 'T:\tempdb\tempdev8.ndf',
    SIZE = 4096MB, FILEGROWTH = 512MB
);

-- Перезапустите SQL Server для применения переноса файлов

После перезапуска SQL Server проверьте, что файлы tempdb переехали на новый диск. Запустите первый запрос повторно — в столбце physical_name должен быть новый путь.

На NVMe-дисках разница между 1 файлом и 8 файлами tempdb — до 30-40% на тяжёлых операциях 1С (закрытие месяца, групповое перепроведение). На SAS-дисках разница ещё больше — до 2-3 раз. Подробнее о влиянии дисков на производительность — в наших результатах тестирования.

Шаг 3 — Настроить параллелизм (MAXDOP)

SQL Server по умолчанию использует все доступные ядра процессора для выполнения одного запроса (MAXDOP = 0). Звучит хорошо, но для 1С это антипаттерн. 1С:Предприятие 8.3 генерирует тысячи коротких OLTP-запросов: прочитать документ, записать регистр, обновить остаток. Каждый запрос выполняется за миллисекунды. Затраты на координацию параллельных потоков для таких запросов превышают выигрыш от параллелизма.

Рекомендация для 1С: MAXDOP = 1. Каждый запрос выполняется одним потоком. Нет накладных расходов на параллелизм. Нет ожиданий CXPACKET в статистике. Рекомендация 1С, подтверждённая на практике. На серверах с 50+ пользователями переключение MAXDOP с 0 на 1 ускоряет проведение документов на 10-20%.

Cost Threshold for Parallelism = 50. Этот параметр задаёт порог стоимости запроса, начиная с которого оптимизатор рассматривает параллельный план. По умолчанию — 5 (слишком низкий порог, параллелятся даже простые запросы). При MAXDOP = 1 параметр формально не влияет. Но если вы вернёте MAXDOP > 1 — порог 50 защитит от ненужной параллелизации коротких запросов 1С.

-- Настроить параллелизм для 1С
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

-- MAXDOP = 1 (один поток на запрос)
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;

-- Cost Threshold = 50 (страховка на случай MAXDOP > 1)
EXEC sp_configure 'cost threshold for parallelism', 50;
RECONFIGURE;

-- Проверить
SELECT name, value_in_use
FROM sys.configurations
WHERE name IN ('max degree of parallelism', 'cost threshold for parallelism');

Настройки применяются мгновенно. Перезагрузка SQL Server не требуется. Новые параметры влияют на все запросы, начиная со следующего.

Исключение: на том же SQL Server работают аналитические запросы (отчёты, OLAP). Задайте MAXDOP = 4 на уровне аналитической базы: ALTER DATABASE [AnalyticsDB] SET MAXDOP = 4. Базы 1С останутся с MAXDOP = 1.

Шаг 4 — Модель восстановления и бэкапы

SQL Server использует одну из трёх моделей восстановления для каждой базы данных: Simple, Full, Bulk-logged. Выбор модели влияет на возможность восстановления данных и на размер журнала транзакций. Для баз 1С актуальны две:

Продуктивные базы 1С — Full. Модель Full позволяет восстановить базу на конкретный момент времени. Если в 14:35 кто-то удалил все документы за квартал — восстанавливаете базу на 14:34. Без модели Full это невозможно.

Обязательное условие при Full: регулярный бэкап журнала транзакций. Без бэкапов лог транзакций растёт бесконечно — до тех пор, пока не заполнит весь диск. Это самая частая проблема после включения Full: администратор переключил модель, но не настроил бэкап лога. Через неделю диск заполнен на 100%, SQL Server остановился, 1С не работает.

-- Проверить текущую модель восстановления всех баз
SELECT name, recovery_model_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

-- Переключить продуктивную базу на Full
ALTER DATABASE [MyBase1C] SET RECOVERY FULL;

-- Сделать полный бэкап (обязателен после переключения на Full)
BACKUP DATABASE [MyBase1C]
TO DISK = N'D:\Backup\MyBase1C_full.bak'
WITH COMPRESSION, INIT;

-- Настроить бэкап лога каждые 15 минут (через SQL Server Agent Job)
-- Или через план обслуживания в SSMS
BACKUP LOG [MyBase1C]
TO DISK = N'D:\Backup\MyBase1C_log.trn'
WITH COMPRESSION, INIT;

Рекомендуемая частота бэкапа лога — каждые 15-30 минут для продуктивных баз с 10+ пользователями. Это даёт RPO (Recovery Point Objective) не более 30 минут — максимальная потеря данных при аварии. Подробная настройка автоматического бэкапа — в руководстве по резервному копированию 1С.

Тестовые и демо-базы — Simple. Не нужен point-in-time recovery, лог очищается автоматически, нет лишних бэкап-заданий. Если у вас есть копия продуктивной базы для тестирования обновлений — переключите её на Simple:

-- Тестовые базы — Simple
ALTER DATABASE [TestBase1C] SET RECOVERY SIMPLE;

Шаг 5 — Статистика и обслуживание индексов

SQL Server использует статистику для построения плана выполнения запросов. Устаревшая статистика — неоптимальный план — медленный запрос. 1С генерирует миллионы изменений в день: новые документы, проведения, записи регистров. Статистика устаревает быстро.

Обязательные настройки для баз 1С:

-- Включить автоматическое обновление статистики
ALTER DATABASE [MyBase1C] SET AUTO_UPDATE_STATISTICS ON;
ALTER DATABASE [MyBase1C] SET AUTO_CREATE_STATISTICS ON;

-- Для баз с 50+ пользователями — асинхронное обновление
-- Запрос не ждёт пересчёта статистики, а использует текущую
ALTER DATABASE [MyBase1C] SET AUTO_UPDATE_STATISTICS_ASYNC ON;

AUTO_UPDATE_STATISTICS_ASYNC — важный параметр для нагруженных баз 1С. Без него SQL Server пересчитывает статистику синхронно: пользователь отправил запрос, SQL Server обнаружил устаревшую статистику, остановил запрос, пересчитал, продолжил. Пользователь ждёт лишние 2-10 секунд. С асинхронным режимом запрос выполняется сразу (на текущей статистике), пересчёт идёт в фоне.

Обслуживание индексов. Индексы фрагментируются по мере вставки и удаления данных. Фрагментированный индекс читает больше страниц с диска — запрос работает медленнее. Регулярное обслуживание индексов сокращает время тяжёлых операций 1С (формирование отчётов, закрытие месяца) на 20-50%.

-- Проверить фрагментацию индексов базы 1С
SELECT
    OBJECT_NAME(ips.object_id) AS table_name,
    i.name AS index_name,
    ips.avg_fragmentation_in_percent,
    ips.page_count
FROM sys.dm_db_index_physical_stats(
    DB_ID('MyBase1C'), NULL, NULL, NULL, 'LIMITED'
) ips
JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.avg_fragmentation_in_percent > 10
  AND ips.page_count > 1000
ORDER BY ips.avg_fragmentation_in_percent DESC;

-- REORGANIZE (для фрагментации 10-30%)
ALTER INDEX ALL ON [dbo].[_InfoRg12345] REORGANIZE;

-- REBUILD (для фрагментации >30%)
ALTER INDEX ALL ON [dbo].[_InfoRg12345] REBUILD;

Для автоматизации используйте скрипт Ola Hallengren (ola.hallengren.com) — бесплатное решение для обслуживания индексов SQL Server. Установите его процедуры и настройте запуск через SQL Server Agent раз в сутки. Скрипт сам определяет уровень фрагментации и выбирает REORGANIZE или REBUILD для каждого индекса.

Шаг 6 — Сжатие данных

PAGE compression (сжатие на уровне страниц) уменьшает размер базы 1С на 60-80%. База весом 50 ГБ после сжатия занимает 10-20 ГБ. Это не только экономия места. Сжатая база быстрее читается с диска (меньше страниц = меньше I/O), а затраты процессора на распаковку минимальны на современных Xeon.

PAGE compression доступна в SQL Server Standard Edition начиная с версии 2016 SP1. До этого — только в Enterprise. Если у вас SQL Server 2016 SP1 или новее на любой редакции — включайте сжатие.

Когда включать: для баз 1С размером от 10 ГБ. На маленьких базах (1-5 ГБ) выигрыш незаметен — база и так помещается в буферный пул целиком.

-- Оценить выигрыш от сжатия для конкретной таблицы
EXEC sp_estimate_data_compression_savings
    @schema_name = 'dbo',
    @object_name = '_InfoRg12345',
    @index_id = NULL,
    @partition_number = NULL,
    @data_compression = 'PAGE';

-- Включить PAGE compression для одной таблицы
ALTER TABLE [dbo].[_InfoRg12345]
REBUILD WITH (DATA_COMPRESSION = PAGE);

-- Включить PAGE compression для всех таблиц базы (скрипт)
DECLARE @sql NVARCHAR(MAX) = '';

SELECT @sql = @sql +
    'ALTER TABLE ' + QUOTENAME(s.name) + '.' + QUOTENAME(t.name) +
    ' REBUILD WITH (DATA_COMPRESSION = PAGE);' + CHAR(13)
FROM sys.tables t
JOIN sys.schemas s ON t.schema_id = s.schema_id
WHERE t.type = 'U';

EXEC sp_executesql @sql;

Сжатие выполняется онлайн в Enterprise Edition. В Standard — таблица блокируется на время REBUILD. Для баз 1С с круглосуточным доступом планируйте сжатие на ночное время или выходные. Крупные таблицы (регистры накопления, регистры бухгалтерии) можно сжимать по одной, не трогая всю базу разом.

После сжатия убедитесь, что SQL Server использует высвободившееся место эффективно. Выполните DBCC SHRINKFILE для уменьшения файла данных — но только разово, после первого сжатия. Регулярный SHRINKFILE вреден: он фрагментирует файл данных и замедляет работу. Узнать, какая редакция SQL Server подходит для ваших задач, можно в отдельной статье.

Пошаговая инструкция: оптимизация SQL Server для 1С 8.3

Дополнительные настройки

Два параметра, которые не влияют на логику работы SQL Server, но существенно ускоряют файловые операции и защищают буферный пул. Настраиваются на уровне Windows, не через T-SQL.

Instant File Initialization

Когда SQL Server создаёт или расширяет файл данных, Windows по умолчанию заполняет весь новый объём нулями (zero-fill). Для файла 10 ГБ это занимает 30-60 секунд. Instant File Initialization пропускает обнуление — файл создаётся мгновенно.

Это важно для 1С по двум причинам. Первая — autogrowth. Если файл базы или tempdb расширяется на 512 МБ, без IFI SQL Server замораживает все операции записи на 2-5 секунд. Пользователи видят зависание. С IFI — расширение происходит мгновенно. Вторая — восстановление из бэкапа. Restore базы 50 ГБ без IFI занимает на 5-10 минут дольше из-за zero-fill.

Как включить:

• Откройте secpol.msc (Локальная политика безопасности)
• Перейдите: Локальные политики → Назначение прав пользователя
• Найдите «Perform volume maintenance tasks» (Выполнение задач обслуживания томов)
• Добавьте учётную запись, под которой работает служба SQL Server (обычно NT Service\MSSQLSERVER)
• Перезапустите SQL Server

-- Проверить, включена ли Instant File Initialization
EXEC sys.xp_readerrorlog 0, 1, N'Instant File Initialization';
-- Если в логе есть строка "Instant File Initialization is enabled" — настройка работает

Lock Pages in Memory

Windows может вытеснить часть буферного пула SQL Server в файл подкачки (pagefile), даже если физической памяти достаточно. Это происходит при пиковой нагрузке, когда другие процессы запрашивают много памяти. Для SQL Server вытеснение буферного пула катастрофично — данные, которые были в RAM, теперь читаются с диска. Запросы 1С замедляются в 10-100 раз.

Lock Pages in Memory запрещает Windows вытеснять буферный пул в pagefile. Буферный пул остаётся в физической памяти — предсказуемая производительность без просадок.

Когда включать: на серверах с 64 ГБ+ RAM, где SQL Server получает 48+ ГБ через max server memory. На серверах с 16-32 ГБ RAM выигрыш минимален.

Как включить:

• Откройте secpol.msc
• Локальные политики → Назначение прав пользователя
• Найдите «Lock pages in memory» (Блокировка страниц в памяти)
• Добавьте учётную запись SQL Server
• Перезапустите SQL Server

-- Проверить, использует ли SQL Server Lock Pages in Memory
SELECT sql_memory_model_desc FROM sys.dm_os_sys_info;
-- "LOCK_PAGES" = включено
-- "CONVENTIONAL" = выключено

Обе настройки требуют перезагрузки службы SQL Server. Планируйте перезагрузку в нерабочее время. Влияние на производительность — косвенное, но ощутимое: меньше задержек при autogrowth (IFI) и стабильная работа при пиковых нагрузках (Lock Pages). Требования к серверному оборудованию для стабильной работы 1С описаны в отдельном руководстве.

Типичные ошибки

Три ошибки, которые сводят на нет любую оптимизацию SQL Server для 1С. Каждая встречается на каждом втором сервере.

SQL Server съел всю память — нет max server memory

Симптомы: 1С тормозит, rphost постоянно перезапускается, в диспетчере задач SQL Server занимает 95-100% RAM. Причина — max server memory не ограничен (по умолчанию 2 147 483 647 МБ, то есть фактически без лимита).

SQL Server — «жадная» СУБД по дизайну. Он кеширует все прочитанные данные в буферный пул и не отдаёт память обратно ОС добровольно. Это нормально для выделенного SQL-сервера. Но если на том же сервере работают rphost 1С, они конкурируют за память с SQL Server — и проигрывают.

Решение: настройте max server memory по формуле из Шага 1. Применяется мгновенно, перезагрузка не нужна. После применения SQL Server начнёт высвобождать память в течение нескольких минут. Если 1С не видит базу данных — проверьте, не упал ли SQL Server из-за нехватки памяти.

tempdb на одном файле — блокировки allocation contention

Симптомы: при 20+ пользователях 1С периодически «подвисает» на 1-3 секунды. В sys.dm_os_wait_stats видны ожидания PAGELATCH_UP и PAGELATCH_EX для базы tempdb. В Activity Monitor — блокировки на системных страницах tempdb.

Причина: при одном файле tempdb все потоки конкурируют за одни и те же страницы PFS/GAM/SGAM. Это горлышко бутылки — одновременно создавать временные таблицы может только один поток. Остальные ждут.

Решение: добавьте файлы tempdb по числу ядер (максимум 8), одинакового размера. После добавления файлов нагрузка на allocation pages распределяется между файлами — contention исчезает. Эффект заметен сразу, особенно на операциях, которые массово создают временные таблицы: закрытие месяца, групповое проведение, сложные отчёты.

MAXDOP по умолчанию — параллельные планы тормозят 1С

Симптомы: в sys.dm_os_wait_stats доминирует тип ожидания CXPACKET. Отдельные запросы 1С выполняются долго, хотя процессор загружен слабо. В планах выполнения (SET STATISTICS XML ON) — Parallelism операторы с перекосом (один поток сделал 99% работы, остальные ждали).

Причина: SQL Server распараллелил простой OLTP-запрос 1С на 16 потоков. Накладные расходы на координацию потоков превысили время самого запроса. Вместо 5 мс запрос выполняется 50 мс — в 10 раз медленнее.

Решение: MAXDOP = 1 для сервера. Одна команда T-SQL, мгновенный эффект, перезагрузка не нужна. После переключения CXPACKET-ожидания исчезают из топа wait statistics. Проведение документов ускоряется на 10-20%.

Вопросы и ответы

Итог

Оптимизация MS SQL Server для 1С 8.3 — восемь настроек, которые превращают «коробочный» SQL Server в СУБД, заточенную под нагрузку 1С:Предприятие. Главные три: ограничить память (max server memory), настроить tempdb на отдельном NVMe с 8 файлами, установить MAXDOP = 1. Эти три параметра дают 80% результата.

Остальные пять (модель восстановления, статистика, обслуживание индексов, сжатие данных, IFI + Lock Pages) закрывают оставшиеся 20% и стабилизируют работу под нагрузкой. Весь процесс занимает 1-2 часа с одной перезагрузкой SQL Server.

Производительность SQL Server зависит не только от настроек, но и от оборудования. На серверах с NVMe-дисками и частотой процессора от 3.0 ГГц оптимизация даёт максимальный эффект. Требования к серверу — в руководстве по подбору оборудования. Результаты тестирования разных конфигураций — на странице методологии.

Если нужна помощь с оптимизацией SQL Server, настройкой бэкапов или подбором серверного оборудования для 1С — оставьте заявку.