Зависает сервер 1С раз в неделю: почему это происходит и как решить проблему?

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

Анализ причин зависания сервера

Чаще всего подобное поведение наблюдается при работе ресурсоемких конфигураций, таких как «1С:Документооборот» (ДО), которая генерирует большое количество фоновых заданий (маршрутизация, полнотекстовый поиск). Рассмотрим основные факторы, приводящие к «заморозке» процессов:

1. Нестабильность релиза платформы: Версии из ветки 8.3.18 (включая 1363) имеют известные проблемы с зависанием рабочих процессов, особенно при интенсивном запуске новых сеансов.
2. Внешние сетевые запросы: Фоновые задания часто обращаются к внешним ресурсам (почта, веб-сервисы, FTP). Если внешний ресурс не отвечает, процесс rphost может зависнуть в бесконечном ожидании, что не фиксируется в технологическом журнале как ошибка.
3. Конфликт портов отладки: При наличии нескольких серверов или баз могут пересекаться порты отладки, что приводит к генерации огромных логов и сбоям маршрутизации.
4. Настройки кластера: Включение опции «Менеджер под каждый сервис» заставляет сервер плодить избыточное число процессов, что усугубляет ситуацию.

Решение 1: Скрипт «мягкого» перезапуска рабочих процессов (rphost)

Если обновление платформы пока невозможно, настроим автоматический «мягкий» перезапуск рабочих процессов. Это решение позволяет серверу создать новый процесс, перевести на него активные сеансы и безопасно завершить зависший. Проанализируем шаги настройки скрипта:

Для работы потребуется установленный сервер администрирования (утилита ras). Скрипт будет использовать команду rac для изменения параметров кластера. Создадим CMD-файл со следующим содержимым:

"c:\Program Files\1cv8\8.3.18.1363\bin\rac.exe" cluster update --cluster=cluster_ID --lifetime-limit 60
timeout /t 90 /nobreak
"c:\Program Files\1cv8\8.3.18.1363\bin\rac.exe" cluster update --cluster=cluster_ID --lifetime-limit 0

Разберем по шагам, что делает этот код:

1. Скрипт меняет параметр кластера «Интервал перезапуска рабочих процессов» на 60 секунд.
2. Далее устанавливается пауза в 90 секунд (команда timeout). За это время сервер 1С успевает создать новые rphost и перенести на них «живые» сеансы.
3. Затем скрипт возвращает параметр интервала перезапуска в 0 (бесконечность).

Важно: Замените 8.3.18.1363 на актуальную версию вашей платформы, а cluster_ID — на идентификатор вашего кластера (его можно получить командой rac.exe cluster list). Рекомендуется настроить планировщик Windows на запуск этого скрипта ежесуточно (например, в 3 часа ночи).

Решение 2: Точечное удаление зависших процессов

Если сервер завис в разгар рабочего дня и перезапуск всей службы нежелателен, применим метод точечной изоляции:

1. Откроем консоль администрирования серверов 1С и найдем рабочий процесс (rphost), в котором скопились зависшие соединения.
2. В свойствах этого процесса установим признак «Не использовать». Если процесс в кластере всего один, предварительно создадим новый.
3. Сервер 1С постепенно сам переведет все новые и активные здоровые сеансы на доступные процессы.
4. Когда в отключенном процессе останутся только «мертвые» фоновые соединения, посмотрим его PID в консоли и принудительно завершим этот rphost.exe через Диспетчер задач Windows.

Решение 3: Очистка серверных кэшей и оптимизация СУБД

Выясним другие причины, очистив сеансовые данные и проверив состояние СУБД:

1. Очистка кэша: Остановим службу Агента сервера 1С. Перейдем в каталог C:\Program Files (x86)\1cv8\srvinfo\reg_1541 и удалим (или очистим) папку snccntx_. После этого запустим службу.
2. Проверка TempDB: Если используется MS SQL Server, настроим счетчики производительности Windows. Пристально покопаем в сторону базы tempdb. Обратите внимание на «Очередь к диску» (Disk Queue Length), время доступа и свободное пространство в момент зависания фоновых заданий.

Решение 4: Изоляция портов отладки

Если вы запускаете службу агента с ключом -debug, проверьте строку запуска. Возможны конфликты, если у вас несколько серверов 1С. В строку запуска службы (в реестре) пропишем явно диапазон портов для отладчика с помощью ключа -debugServerPort. Пример строки запуска:

"C:\Program Files\1cv8\8.3.18.1363\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug -debugServerPort 1595

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

Итоги

Зависание серверов 1С на ветке 8.3.18 при работе с фоновыми заданиями — известная архитектурная особенность данного релиза. Пока вы планируете переход на более новую платформу (например, 8.3.21 или выше), использование скрипта мягкого перезапуска через rac.exe является самым надежным способом предотвратить внезапные остановки работы предприятия.