Почему MS SQL Server аномально нагружает процессор и как решить проблему зависшего динамического обновления 1С?

← На главную

Каждый администратор крупных информационных систем на базе «1С:Предприятие» рано или поздно сталкивается с ситуацией, когда сервер СУБД MS SQL Server внезапно начинает потреблять до 100% ресурсов процессора (CPU). При этом со стороны пользователей жалоб на тяжелые отчеты или групповые обработки может не поступать, а технологический журнал не показывает явных длительных транзакций. Монитор ресурсов демонстрирует, что основную нагрузку генерируют рабочие процессы сервера приложений 1С (rphost), которые непрерывно засыпают SQL-сервер тяжелыми запросами.

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

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

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

Проверка диспетчера задач и монитора ресурсов. Обратим внимание на загрузку процессора и оперативной памяти. Если процессы sqlservr.exe и rphost.exe делят между собой практически все ресурсы CPU, а дисковая очередь при этом остается минимальной, это первый признак зацикливания логики выполнения запросов.
Исключение влияния стороннего софта. Убедимся, что на сервере баз данных и сервере приложений не запущены сторонние ресурсоемкие службы. Например, антивирусное ПО или серверы управления безопасностью (такие как Kaspersky Security Center) могут использовать собственные экземпляры MS SQL, создавая фоновую нагрузку. Убедимся, что загружен именно рабочий экземпляр СУБД, обслуживающий базы 1С.
Использование Монитора активности (Activity Monitor) в SSMS. Откроем среду SQL Server Management Studio, подключимся к нашему серверу, нажмем правой кнопкой мыши на имя сервера и выберем Activity Monitor. В разделе «Active Expensive Queries» (Активные ресурсоемкие запросы) мы увидим, какие именно инструкции выполняются в данный момент. Если мы замечаем непрерывное выполнение запросов к таблице Config с выборкой больших объемов данных, это главный симптом повреждения конфигурации.

Рассмотрим детально, почему штатный механизм платформы 1С приводит к столь разрушительным последствиям для производительности СУБД.

Механизм возникновения сбоя при динамическом обновлении

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

В процессе штатного обновления СУБД задействует две основные таблицы:

Config — хранит актуальную рабочую конфигурацию базы данных.
ConfigSave — используется для сохранения конфигурации в процессе редактирования в Конфигураторе.

Когда администратор запускает динамическое обновление, в таблице Config создаются специальные служебные записи (маркеры), сигнализирующие системе о начале процесса фиксации изменений. После успешного завершения транзакции эти маркеры удаляются. Однако, если в момент сохранения конфигурации происходит сбой — например, сетевое прерывание связи между сервером приложений и СУБД, аварийное завершение процесса rphost или принудительное закрытие Конфигуратора пользователем — транзакция завершается некорректно.

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

Пошаговый алгоритм очистки «мертвых» обновлений в MS SQL

Если мы столкнулись с описанной проблемой, её решение лежит в плоскости ручной корректировки таблиц конфигурации на уровне СУБД. Разберем этот процесс по шагам.

Важное предупреждение: Любые операции прямого изменения данных в СУБД в обход платформы 1С крайне опасны. Перед началом работ обязательно сделайте резервную копию базы данных (резервную копию SQL или средствами выгрузки в .dt)!

Шаг 1. Подготовка и остановка служб

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

Остановим службу 1C:Enterprise 8.3 Server Agent через оснастку «Службы» (services.msc) или с помощью командной строки:

net stop "1C:Enterprise 8.3 Server Agent"

Шаг 2. Очистка таблиц конфигурации в SQL Server Management Studio

Откроем среду SSMS, выберем нашу проблемную базу данных и создадим новый запрос. Нам необходимо выполнить очистку таблицы незавершенных сохранений ConfigSave и удалить маркеры динамического обновления из таблицы Config.

Проанализируем и выполним следующий SQL-скрипт:


-- Шаг 2.1. Полностью очищаем таблицу ConfigSave от незавершенных сохранений
TRUNCATE TABLE dbo.ConfigSave;

-- Шаг 2.2. Удаляем служебные маркеры блокировок и обновлений из таблицы Config
DELETE FROM dbo.Config 
WHERE FileName IN ('commit', 'dbStruFinal', 'dynamicCommit', 'DynamicallyUpdated');

Рассмотрим, за что отвечают удаляемые маркеры в поле FileName:

commit — маркер начала транзакции записи конфигурации.
dbStruFinal — признак завершения реструктуризации базы.
dynamicCommit и DynamicallyUpdated — служебные флаги платформы 1С версии 8.3, указывающие на наличие незавершенных или активных сессий динамического обновления.

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

Шаг 3. Очистка серверного и локального кэша метаданных

Если мы просто запустим сервер 1С после очистки таблиц в SQL, высока вероятность, что рабочие процессы сервера приложений продолжат использовать старый кэш метаданных, хранящийся на диске сервера. Это может спровоцировать повторное зацикливание или вызвать у пользователей критическую ошибку «Ошибка формата потока» при запуске сеанса.

Выполним очистку кэша на сервере приложений 1С по следующей схеме:

Перейдем в каталог профиля пользователя, от имени которого запущена служба сервера 1С (по умолчанию это локальная системная учетная запись или специально созданный пользователь, например usr1cv8).
Путь к кэшу обычно выглядит следующим образом: C:\Users\usr1cv8\AppData\Local\1C\1Cv8 (или в папке Roaming).
Внутри этого каталога найдем папки с уникальными идентификаторами баз данных (UUID). Нам необходимо зайти в папку нашей проблемной базы и физически удалить подкаталоги с именами:
- Config
- ConfigSave
- DBNameCache
- SICache

После удаления серверного кэша запустим службу сервера приложений 1С обратно:

net start "1C:Enterprise 8.3 Server Agent"

Также рекомендуется очистить локальный кэш на компьютерах пользователей, у которых наблюдались проблемы с запуском системы после сбоя. Самый простой способ сделать это — удалить базу из списка запуска в стартере 1С и добавить её заново (при этом папка кэша с UUID пересоздастся автоматически).