← На главную

При выполнении реструктуризации или обновлении конфигурации базы данных разработчики и системные администраторы нередко сталкиваются с ошибкой: система сообщает, что база занята другим монопольным соединением (например, сеансом Конфигуратора многодневной давности). При этом стандартный список сеансов и соединений в консоли администрирования кластера пуст, а автоматическое завершение соединений не срабатывает. Разберем по шагам, почему возникает эта проблема и как снять блокировку без остановки всей службы ragent.

Выясним причину возникновения невидимых блокировок

Проанализируем ситуацию, которая приводит к зависанию монопольного режима. В платформе 1С:Предприятие за учет сеансов и управляемых блокировок отвечает менеджер кластера (rmngr), а выполнение пользовательского кода происходит в рабочих процессах (rphost). Рассинхронизация между ними возникает по следующим причинам:

1. Аварийное завершение процесса rphost без оповещения менеджера: если рабочий процесс аварийно завершился («упал») или завис, rmngr продолжает считать зарегистрированные в нем соединения активными до истечения внутренних таймаутов пинга. В консоли управления такой процесс может отображаться со статусом «активный», оставаясь фактически «зомби».
2. Зависшие сетевые соединения (Half-open TCP): при некорректном отключении клиентской машины (обрыв связи, выключение ПК) сетевой сокет на сервере может оставаться в состоянии ESTABLISHED. Менеджер кластера ожидает ответа от клиента и продолжает удерживать исключительную блокировку метаданных.
3. Кэширование данных в графической консоли MMC: оснастка администрирования может отображать устаревший список соединений и сеансов, скрывая реальные идентификаторы зависших потоков.

Способ 1. Изоляция и точечное завершение зависшего процесса rphost

Если на сервере приложений работает несколько баз или пользователей, перезапуск всей службы ragent приведет к простою. Рассмотрим, как адресно устранить проблемный процесс:

1. Откроем консоль администрирования серверов 1С:Предприятия и перейдем в ветку Рабочие процессы нужного кластера.
2. Найдем процесс, на котором зарегистрирована проблемная информационная база, либо процесс, переставший отвечать на запросы. Зафиксируем его сетевой порт и системный идентификатор (PID).
3. Переведем проблемный рабочий процесс в режим Использование = Не использовать. Это предотвратит распределение новых сеансов на данный процесс. При необходимости создадим временный новый рабочий процесс, чтобы кластер мог перевести валидные сеансы на него.
4. Откроем диспетчер задач операционной системы (или терминал в Linux) и принудительно завершим процесс с зафиксированным идентификатором: taskkill /PID <PID_процесса> /F или для ОС Linux: kill -9 <PID_процесса>
5. После завершения процесса менеджер кластера rmngr сбросит удерживаемые им блокировки, после чего можно повторить обновление конфигурации.

Способ 2. Принудительное удаление сеансов через утилиту командной строки RAC

Поскольку графическая оснастка администрирования может скрывать фантомные сессии, воспользуемся консольной утилитой rac, работающей напрямую через службу администрирования ras. Разберем по шагам последовательность команд:

1. Получим список всех сеансов информационной базы, включая спящие и зависшие: rac session list --cluster=<ID_кластера> --ibase=<ID_базы>
2. В полученном списке найдем идентификатор (session) зависшего сеанса конфигуратора.
3. Выполним принудительное удаление найденного сеанса: rac session terminate --cluster=<ID_кластера> --session=<ID_сеанса>
4. Аналогичным образом проверим список соединений командой rac connection list и выполним отключение зависшего сокета через rac connection disconnect.

Способ 3. Создание дублирующей регистрации базы (быстрый обходной путь)

Если проблема возникла на базе разработки или тестовом стенде, а доступ к консоли ОС ограничен, применим эффективный обходной маневр:

1. В консоли администрирования кластера создадим новую информационную базу и укажем параметры подключения к той же самой физической базе данных на сервере СУБД (SQL).
2. Зададим новой записи уникальное имя в рамках кластера (например, добавив суффикс _temp).
3. Откроем Конфигуратор через вновь созданное имя базы в кластере.
4. Успешно выполним сохранение и реструктуризацию конфигурации — блокировка старого имени кластера не затронет новое логическое подключение к СУБД. При использовании хранилища конфигурации достаточно подтвердить смену пути к информационной базе.

Параметры кластера для предотвращения зависаний

Чтобы свести к минимуму появление «зомби»-процессов и зависших блокировок в будущем, настроим параметры кластера и информационных баз:

1. Интервал перезапуска рабочих процессов: зададим значение 86400 секунд (перезапуск раз в сутки). Это предотвратит деградацию процессов из-за фрагментации памяти.
2. Параметр «Выключенные процессы останавливать через»: установим интервал от 60 до 120 секунд. Если этот параметр равен 0, выключенные и проблемные процессы остаются в оперативной памяти бесконечно.
3. Ограничение процессов и соединений: в высоконагруженных базах стабильность повышается при выделении отдельных рабочих процессов под базу и ограничении количества соединений (например, до 25–50 соединений на один rphost).
4. Таймауты спящих сеансов: в параметрах каждой информационной базы укажем Время засыпания пассивных сеансов (например, 1200 сек) и Время завершения спящих сеансов (например, 86400 сек), чтобы сервер автоматически очищал потерянные клиентские подключения.