← На главную

В процессе администрирования крупных или многобазовых кластеров 1С:Предприятие системные администраторы часто сталкиваются со специфической проблемой: в определенные часы (например, после обеда) пользователи не могут войти в базу. При этом у тех, кто уже работает, сеансы продолжают функционировать, но при попытке открыть новое подключение система «зависает» на этапе загрузки. Попытка открыть Консоль администрирования серверов 1С приводит к ее длительному зависанию, после чего выдается критическая ошибка: «Ошибка операции администрирования. Не найдено ни одного сервера с размещенным сервисом serviceName = SessionData Service...».

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

Почему возникает ошибка SessionData Service?

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

Основными триггерами этой проблемы являются:

1. Тяжелые регламентные и фоновые задания. Запуск ресурсоемких обработок (например, закрытие месяца, обновление индексов полнотекстового поиска, выгрузка данных) в одной из баз кластера может полностью заблокировать менеджер кластера.
2. Блокировка портов. Активная работа фоновых заданий может исчерпать доступный пул портов (по умолчанию 1560–1591), переводя порты в состояние TIME_WAIT, что делает невозможным установку новых соединений с сервисом сеансов.
3. Переполнение сессионного кэша. Накопление временных файлов сессий в каталоге сервера 1С приводит к задержкам на уровне дисковой подсистемы при обращении к папкам сессий.

Рассмотрим подробнее методы устранения данной проблемы и профилактические меры для предотвращения ее повторения.

Решение 1. Оптимизация и отключение регламентных заданий

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

1. Проанализируем список регламентных и фоновых заданий во всех базах, подключенных к кластеру. Особое внимание следует уделить недавно добавленным или обновленным информационным базам.
2. Временно отключим тяжелые регламентные операции, выполняющиеся в период пиковой нагрузки (например, с 14:00 до 17:00). Для этого можно использовать консоль администрирования (свойства базы — флаг «Блокировка регламентных заданий включена») или обработку «Консоль регламентных заданий».
3. Если после отключения заданий зависания прекратились, необходимо оптимизировать код этих процедур или перенести их выполнение на нерабочее (ночное) время.

Решение 2. Очистка кэша сессионных данных сервера 1С

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

1. Остановим службу агента сервера 1С:Предприятие. В консоли служб Windows (services.msc) найдем службу 1C:Enterprise 8.3 Server Agent и нажмем «Остановить».
2. Перейдем в каталог данных кластера. По умолчанию он находится по пути: C:\Program Files\1cv8\srvinfo\ (или C:\ProgramData\1C\1cv8\ в зависимости от версии и настроек установки).
3. Зайдем в каталог конкретного порта кластера (например, reg_1541).
4. Найдем и безвозвратно удалим все папки, название которых начинается с префикса snccntx (например, snccntx5e7b...). В этих папках хранятся кэшированные данные сессий, которые будут автоматически пересозданы при запуске.
5. Дополнительно очистим кэш пользователя, от имени которого запускается служба 1С (обычно это локальный пользователь USR1CV8). Удалим содержимое папок по путям:
   • %localappdata%\1C\1cv8
   • %appdata%\1C\1cv8
6. Запустим службу агента сервера 1С:Предприятие.

Решение 3. Изоляция сервисов кластера (Менеджер под каждый сервис)

Чтобы падение или зависание одного сервиса (например, сервиса фоновых заданий) не приводило к отказу всего кластера и блокировке SessionDataService, настроим разделение процессов rmngr:

1. Откроем Консоль администрирования серверов 1С.
2. Перейдем к свойствам нашего кластера.
3. Найдем параметр «Режим распределения нагрузки» или настройки рабочих серверов. В современных версиях платформы рекомендуется использовать требования назначения функциональности (ТНФ).
4. Настроим систему таким образом, чтобы критически важные сервисы (включая SessionDataService) и сервисы фоновых заданий выполнялись на разных рабочих серверах или обслуживались отдельными процессами менеджера. Для этого добавим требование назначения функциональности: «Для всех объектов» -> «Сервис фоновых заданий» -> «Не назначать» на основном сервере, и «Назначать» на выделенном рабочем сервере.

Решение 4. Расширение диапазона рабочих портов

Если регламентные задания порождают тысячи кратковременных подключений, стандартного пула портов 1560–1591 может не хватить. Увеличим диапазон портов для рабочих процессов:

1. Остановим службу 1С.
2. Откроем редактор реестра Windows (regedit) и перейдем по пути: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent.
3. Найдем параметр ImagePath и отредактируем строку запуска службы.
4. Изменим ключ -range 1560:1591 на более широкий диапазон, например, -range 1560:1691.
5. Сохраним изменения и запустим службу.

Применение этих мер в комплексе позволит полностью избавиться от зависаний при входе и исключит появление ошибок лицензирования и администрирования сеансов на сервере 1С.