Администрирование высоконагруженных систем на базе 1С:Предприятие 8.3 часто сопряжено с необходимостью регулярного обслуживания серверного кластера. Одной из наиболее распространенных проблем являются утечки памяти в рабочих процессах rphost.exe и «зависание» пользовательских сеансов. В условиях использования отказоустойчивых решений, таких как Windows Failover Cluster и группы доступности SQL AlwaysOn, обычная остановка службы может не дать желаемого результата: сеансы «присасываются» обратно, а процессы не обновляются. В этой статье мы подробно разберем, как корректно выполнять перезагрузку кластера 1С.
Рассмотрим ситуацию: администратор останавливает службу 1C:Enterprise 8.3 Server Agent, но после запуска обнаруживает, что рабочие процессы имеют старое время запуска, а пользователи мгновенно восстанавливают свои соединения. Разберем по шагам, почему это происходит. Проблема кроется в механизме отказоустойчивости сеансов (Session Resilience), внедренном в платформу 8.3. Платформа сохраняет данные о состоянии сеансов в специальном хранилище (папка snacc), что позволяет пользователям не замечать кратковременных разрывов связи.
Для решения задачи полной очистки нам необходимо не просто перезапустить службу, а принудительно завершить все связанные процессы и, при необходимости, очистить временные файлы. Выясним причину, по которой стандартные средства Windows не всегда справляются с этой задачей в контексте кластера 1С.
Проанализируем наиболее эффективный сценарий ручной перезагрузки, который объединяет остановку служб на всех узлах кластера и принудительное уничтожение «зависших» процессов. Этот метод особенно полезен, когда консоль администрирования не позволяет выключить процессы штатно.
Рассмотрим пример скрипта, адаптированного для работы в двухнодовом кластере:
set logfile="C:\script\restart1C_log.txt"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
echo %date% %time% "Остановка службы на node2" >> %logfile%
sc \\node2 stop %SERVICE_1C_NAME%
timeout 5
echo %date% %time% "Остановка службы на node1" >> %logfile%
sc stop %SERVICE_1C_NAME%
timeout 5
rem Принудительное завершение процессов на удаленном узле
taskkill /s node2 /f /im "rphost.exe"
taskkill /s node2 /f /im "rmngr.exe"
taskkill /s node2 /f /im "ragent.exe"
rem Принудительное завершение процессов на локальном узле
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
echo "Остановка завершена" %date% %time% >> %logfile%
timeout 20
rem Запуск служб в обратном порядке
sc start %SERVICE_1C_NAME%
timeout 10
sc \\node2 start %SERVICE_1C_NAME%
В данном скрипте мы используем команду sc stop для штатной попытки остановки, а затем taskkill с флагом /f для гарантированного закрытия rphost.exe, rmngr.exe и ragent.exe. Важно делать паузы (команда timeout), чтобы операционная система успела освободить занятые процессами ресурсы памяти и дескрипторы файлов.
Посмотрим на ситуацию с другой стороны: вместо того чтобы бороться с последствиями утечек памяти вручную, мы можем заставить кластер 1С обновлять рабочие процессы автоматически. Это наиболее «правильный» способ с точки зрения эксплуатации платформы 8.3.
Для настройки автоматического перезапуска выполним следующие шаги:
rphost будет помечен на удаление.Использование этих настроек позволяет системе плавно переводить пользователей со старых процессов на новые без прерывания их работы. Старый процесс rphost.exe, накопивший утечки памяти, просто закроется сам, как только из него уйдут все активные сеансы или истечет время ожидания.
Если даже после перезагрузки процессов наблюдаются странности в работе или сеансы восстанавливаются вопреки вашему желанию, необходимо выполнить очистку кэша. Рассмотрим подробнее, где 1С хранит эти данные.
Основная информация хранится в каталоге srvinfo (путь к нему указан в свойствах службы ragent). Разберем по шагам алгоритм глубокой очистки:
reg_1541 (номер может отличаться, если порт кластера не стандартный).1Cv8.lst, так как в нем содержится список зарегистрированных баз.snacc — именно здесь хранятся данные о «живучести» сеансов.AppData\Local\Temp).После такой очистки запуск службы займет чуть больше времени, так как системе придется заново формировать кэш, но зато вы получите абсолютно «чистое» состояние системы.
Проанализируем важный аспект: если ваша служба 1С добавлена как ресурс в Windows Failover Cluster, использование команд sc stop может привести к нежелательному эффекту. Кластер Windows может решить, что произошел сбой, и попытается немедленно запустить службу на другом узле.
В такой конфигурации правильно управлять службой через PowerShell или оснастку управления кластером:
Stop-ClusterResource -Name "1C:Enterprise 8.3 Server Agent"
# Выполняем манипуляции с процессами и кэшем
Start-ClusterResource -Name "1C:Enterprise 8.3 Server Agent"
Это гарантирует, что механизмы высокой доступности Windows не будут конфликтовать с вашими действиями по обслуживанию системы.
Для более изящного решения проблемы «присасывания» сеансов, вместо того чтобы убивать процессы через taskkill, мы можем использовать штатную утилиту rac. Рассмотрим сценарий, при котором мы сначала программно выгоняем пользователей.
Алгоритм действий следующий:
rac session terminate завершаем все текущие сеансы.Такой подход минимизирует риск повреждения базы данных и обеспечивает корректное завершение транзакций в SQL Server.
Подведем итог: для эффективной перезагрузки кластера 1С 8.3 в сложных конфигурациях лучше всего комбинировать автоматические настройки самоочистки процессов в консоли администрирования и периодические профилактические перезагрузки с помощью скриптов, которые учитывают специфику Session Resilience и очистку временных файлов snacc.