Как устранить периодические зависания 1С:Предприятие на 1–2 минуты при работе с MS SQL Server

Рассматриваемая нами проблема является классической для клиент-серверной архитектуры 1С:Предприятие на базе MS SQL Server. В процессе рабочего дня пользователи сталкиваются с тем, что программа внезапно «застывает» на 1–2 минуты, не реагируя на действия, а затем самостоятельно продолжает работу в штатном режиме без аварийного завершения сеансов. При этом аппаратные ресурсы сервера могут быть загружены неравномерно, а явных ошибок в системных логах Windows на первый взгляд не обнаруживается.

В этой статье мы подробно разберем причины возникновения таких микрозависаний и по шагам настроим серверную инфраструктуру для достижения максимальной стабильности и быстродействия.

Шаг 1. Анализ и оптимизация рабочих процессов 1С (rphost)

Одной из наиболее частых причин «замирания» системы является некорректная настройка параметров перезапуска рабочих процессов rphost в кластере 1С. Выясним, почему это происходит.

Когда в настройках кластера серверов 1С задан слишком жесткий лимит использования памяти на один процесс (например, устаревшие рекомендации в 4 ГБ для 64-разрядных систем), процесс rphost при достижении этого порога помечается как выключенный, и система начинает создавать новый рабочий процесс. В этот момент происходит перенос сеансов пользователей со старого процесса на новый. Если соединений много (в нашем случае около 50 пользователей и до 10 активных баз), этот процесс вызывает резкий скачок нагрузки на процессоры, из-за чего вся система «замирает» на 1–2 минуты.

Выполним правильную настройку параметров рабочего сервера через консоль администрирования кластера:

1. Откроем Консоль администрирования кластера серверов 1С.
2. Перейдем в ветку Кластеры -> Локальный кластер -> Рабочие серверы.
3. Откроем свойства нашего рабочего сервера.
4. Проанализируем и скорректируем следующие параметры:
   • Максимальный объем памяти рабочих процессов: не устанавливайте этот параметр в жесткие рамки вроде 4 ГБ. На современных 64-битных серверах рекомендуется установить значение 0 (без ограничений), либо выделить под процессы 1С до 80% доступной оперативной памяти сервера (за вычетом доли, зарезервированной под MS SQL Server). Например, если для 1С доступно 40 ГБ, укажите значение порядка 32 212 254 720 байт.
   • Безопасный расход памяти за один вызов: установите значение 0 или в пределах 2–4 ГБ (в байтах), чтобы защитить сервер от падения из-за одного некорректного тяжелого запроса.
   • Количество соединений на рабочий процесс: по умолчанию этот параметр равен 128. Для более стабильной работы и снижения нагрузки при переподключениях рекомендуется уменьшить его до 25–50 соединений. Это приведет к автоматическому созданию нескольких процессов rphost, распределяющих нагрузку более равномерно.

Шаг 2. Тонкая настройка MS SQL Server под специфику 1С

Поскольку базы данных работают под управлением СУБД MS SQL Server (в частности, современных версий вроде SQL Server 2017), дефолтные параметры СУБД часто становятся причиной конфликтов блокировок и неоптимального распределения процессорного времени.

Проанализируем и настроим ключевые параметры MS SQL Server:

1. Настройка ограничения параллелизма (MAXDOP)

По умолчанию параметр max degree of parallelism (MAXDOP) равен 0, что позволяет СУБД задействовать все доступные ядра процессора для выполнения одного тяжелого запроса. На относительно слабых процессорах (например, с частотой 1.80 GHz) это мгновенно парализует выполнение других операций. Установим ограничение:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1;
EXEC sp_configure 'cost threshold for parallelism', 50;
RECONFIGURE;

Настройка MAXDOP = 1 заставляет СУБД выполнять каждый запрос в рамках одного процессорного потока, что гарантирует защиту от монопольного захвата процессора одним неоптимальным запросом. Значение cost threshold for parallelism = 50 предотвращает запуск распараллеливания для простых «дешевых» запросов.

2. Использование старого оптимизатора запросов (Legacy Cardinality Estimation)

Новый оптимизатор запросов, появившийся в SQL Server начиная с версии 2014, часто некорректно оценивает кардинальность временных таблиц 1С, что приводит к созданию крайне неэффективных планов выполнения запросов. Вернем проверенный временем и стабильный алгоритм для баз данных 1С:

USE [Имя_Вашей_Базы_1С];
ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION = ON;

3. Борьба с маскировкой параметров (Parameter Sniffing)

Эффект Parameter Sniffing заключается в том, что SQL Server кэширует план запроса, построенный при первом запуске с конкретными параметрами. Если первый запуск был легким, а второй затребовал огромный массив данных, СУБД попытается применить старый план, что вызовет жесткое зависание дисковой подсистемы. Отключим это поведение на уровне базы данных:

USE [Имя_Вашей_Базы_1С];
ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SNIFFING = OFF;

4. Быстрая инициализация файлов (Instant File Initialization)

При авторасширении файлов базы данных (Autogrow) операционная система по умолчанию заполняет выделяемые новые сектора диска нулями. В этот момент транзакции приостанавливаются, и вся СУБД «ждет» завершения разметки. Чтобы избежать этого, предоставим учетной записи, от которой запущена служба SQL Server, специальное право в Windows.

Откроем Локальная политика безопасности (secpol.msc) -> Локальные политики -> Назначение прав пользователя -> найдем политику Выполнение задач по обслуживанию томов (Perform volume maintenance tasks) и добавим туда пользователя, под которым работает служба SQL Server.

Шаг 3. Оптимизация и разнесение системной базы данных TempDB

Платформа 1С:Предприятие генерирует колоссальное количество временных таблиц в процессе построения отчетов и проведения документов. Все эти данные обрабатываются в системной базе TempDB. Если она настроена некорректно, возникают внутренние ожидания выделения страниц (ошибки типа PAGELATCH).

Выполним оптимизацию TempDB по следующим правилам:

1. Количество файлов данных TempDB должно быть равно числу ядер процессора, но не более 8 (в нашем случае, если у нас 2 процессора, создадим 8 файлов данных одинакового размера).
2. Размер файлов автоувеличения должен быть строго фиксированным (например, по 256 МБ или 512 МБ), а не в процентах.
3. Разместите файлы данных и журналов транзакций TempDB на самом быстром доступном дисковом накопителе (желательно NVMe или SSD), физически отделенном от дисков с основными базами данных.

Шаг 4. Настройка сетевого взаимодействия и Shared Memory

В конфигурациях, где сервер приложений 1С и СУБД MS SQL Server развернуты на одном физическом сервере, по умолчанию обмен данными может происходить через сетевой стек протокола TCP/IP. Это добавляет накладные расходы на маршрутизацию трафика внутри сетевой карты.

Переведем взаимодействие на протокол Shared Memory (общая память):

1. Откроем Диспетчер конфигурации SQL Server (SQL Server Configuration Manager).
2. Перейдем в раздел Сетевая конфигурация SQL Server -> Протоколы для MSSQLSERVER.
3. Убедимся, что протокол Общая память (Shared Memory) включен. При необходимости включим его и перезапустим службу SQL Server.
4. В строке подключения к СУБД на сервере 1С вместо имени сервера или IP-адреса (например, 192.168.1.10) укажите локальное имя: localhost или точку .. Это принудительно заставит процессы 1С обращаться к SQL напрямую через оперативную память, минуя сетевые протоколы.

Шаг 5. Контроль регламентных заданий в базах 1С

Часто фоновые процессы запускаются одновременно, перегружая дисковую систему и процессор. Проанализируем регламентные операции:

• Полнотекстовый поиск (ППД): если пользователи не используют глобальный поиск по всей базе, полностью отключите индексацию полнотекстового поиска через меню «Администрирование» -> «Общие настройки» -> «Полнотекстовый поиск». Постоянное обновление индекса ППД нагружает рабочие процессы rphost.
• Слияние индексов: если полнотекстовый поиск необходим, настройте расписание слияния индексов строго на нерабочее (ночное) время.
• Фоновые задания в неактивных базах: если на сервере развернуто множество баз данных (включая копии и тестовые полигоны), заблокируйте начало сеансов и выполнение регламентных заданий во всех базах, кроме рабочих. Сделать это можно через свойства информационной базы в консоли администрирования 1С.

Шаг 6. Настройка электропитания оборудования

Даже если в операционной системе Windows Server выбран план электропитания «Высокая производительность» (High Performance), процессор на аппаратном уровне может динамически сбрасывать частоты для экономии энергии (так называемые состояния C-States и технология Intel SpeedStep / AMD Cool'n'Quiet).

Для серверов баз данных, особенно со слабой базовой частотой ядер (как в нашем примере — 1.80 GHz), критически важно отключить эти энергосберегающие функции. Перезагрузите сервер, войдите в настройки BIOS/UEFI и переключите профиль управления питанием процессора в режим Static High Performance (Максимальная производительность без динамического изменения частот).

Проведение предложенного комплекса мер гарантированно устранит периодические зависания рабочих процессов, оптимизирует распределение ресурсов памяти и процессора между сервером 1С и СУБД, обеспечив плавную и комфортную работу пользователей.