← На главную

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

Разберем подробно, почему возникает подобное зависание, как изолировать базы друг от друга и как оперативно восстановить доступ к конкретной информационной базе без остановки всего кластера.

Основные причины зависания отдельной информационной базы

Проанализируем ключевые факторы, приводящие к блокировке базы:

1. Последствия динамического обновления конфигурации: при обновлении конфигурации базы данных без монопольного захвата и перезапуска рабочих процессов нередко происходит повреждение или рассинхронизация серверного кэша метаданных (каталоги snccntx), что приводит к зависанию потоков при обращении к системным таблицам Config и Params.
2. Зависшие транзакции и монопольные блокировки в MS SQL Server: если транзакция не завершилась корректно (например, завис фоновый поток или произошел сбой сети), СУБД удерживает монопольные блокировки (X-lock) на уровне таблиц. В таком случае новые сеансы 1С не могут даже инициализировать параметры сеанса при входе.
3. Зависание рабочего процесса rphost: если несколько информационных баз обслуживаются одним общим процессом rphost, сбой или бесконечный цикл в коде одной базы парализует работу остальных баз, привязанных к этому же процессу.
4. Непрерываемые операции ввода-вывода: если сеанс ожидает ответа от дисковой подсистемы или сетевого сокета СУБД, штатная команда кластера 1С на удаление сеанса не может быть выполнена мгновенно.

Решение 1. Изоляция баз через параметр «Количество ИБ на рабочий процесс»

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

Для изоляции баз выполним настройку рабочих серверов в консоли администрирования кластера:

1. Откроем утилиту Консоль администрирования серверов 1С:Предприятия.
2. Перейдем в ветку Кластеры → Рабочие серверы.
3. Откроем свойства нужного рабочего сервера (по умолчанию Центральный сервер).
4. Найдем параметр «Количество ИБ на рабочий процесс» (или «Число ИБ на рабочий процесс») и изменим его значение по умолчанию на 1.
5. Применим изменения. Для перераспределения нагрузки потребуется плановый перезапуск службы сервера 1С или естественное пересоздание процессов по расписанию.

Преимущества данной настройки:

1. Каждая информационная база будет обслуживаться собственным выделенным процессом rphost (или несколькими процессами, закрепленными только за ней).
2. На многоядерных серверах повышается общая производительность за счет более эффективного распределения потоков по ядрам CPU.
3. В случае зависания базы администратор может принудительно завершить только связанный с ней процесс rphost, не затрагивая пользователей соседних информационных баз.

Решение 2. Определение и принудительное завершение конкретного процесса rphost по PID

Если база перестала отвечать, а стандартная команда удаления сеансов не помогает, снимем зависший рабочий процесс операционной системы по его идентификатору (PID):

1. В консоли администрирования 1С перейдем в раздел Рабочие процессы.
2. Раскроем список соединений каждого процесса и определим, какой именно процесс обслуживает проблемную информационную базу.
3. В свойствах рабочего процесса посмотрим значение поля PID (идентификатор процесса в операционной системе).
4. Откроем Диспетчер задач Windows (Task Manager) или утилиту Resource Monitor, перейдем на вкладку «Подробности» (Details), найдем процесс rphost.exe с соответствующим PID и завершим его аварийно («Снять задачу»).
5. Кластер 1С автоматически перезапустит упавший рабочий процесс, после чего пользователи смогут войти в базу без перезагрузки всей службы ragent.

Решение 3. Снятие блокирующих транзакций на стороне MS SQL Server

Если процесс rphost активен, но база не пускает пользователей, проверим наличие спящих блокирующих транзакций в СУБД:

1. Откроем SQL Server Management Studio (SSMS).
2. Выполним системную процедуру для поиска блокировок: sp_who2
3. В выводе процедуры найдем строки, относящиеся к нашей базе данных, и обратим внимание на колонку BlkBy (Blocked By). Если там указан номер другой сессии (SPID), значит, текущие запросы заблокированы.
4. Снимем зависшую блокирующую сессию командой: KILL <SPID_блокирующей_сессии>
5. После отката зависшей транзакции в MS SQL Server доступ к базе восстанавливается практически мгновенно.

Решение 4. Автоматизация контроля процессов и предотвращение сбоев

Для минимизации ручного вмешательства настроим встроенные механизмы самовосстановления кластера серверов 1С:

1. В свойствах кластера серверов зададим параметры:
   • Интервал перезапуска рабочих процессов: установим значение 86400 секунд (1 раз в сутки для очистки фрагментации памяти).
   • Проблемные процессы завершать через: установим значение от 30 до 60 секунд. Это позволит кластеру автоматически уничтожать зависшие процессы без участия администратора.
2. В свойствах проблемной информационной базы при сбоях включим опцию «Блокировка регламентных заданий включена», чтобы фоновые задания не захватывали ресурсы в момент восстановления.
3. Исключим использование динамического обновления конфигурации на рабочих базах: любые изменения следует применять исключительно монопольно с последующим перезапуском сеансов.