Почему в кластере 1С увеличивается количество рабочих процессов до 32 и возникает ошибка сетевого доступа 10054?

Системный администратор 1С v8.3 (Обычные формы) IT и автоматизация бизнеса
← На главную

При администрировании клиент-серверной архитектуры 1С:Предприятие 8.3 администраторы нередко сталкиваются с ситуацией, когда число рабочих процессов rphost непрерывно растет, достигает отметки в 32 штуки и переходит в неактивное состояние. После этого пользователи теряют доступ к базе, а в журнале или на клиентах появляется сообщение: server_addr=tcp://srv-1c:1571 descr=Ошибка сетевого доступа к серверу (Windows Sockets — 10054(0x00002746). Удаленный хост принудительно разорвал существующее подключение.). Проанализируем природу этой неисправности и разберем по шагам действенные методы ее устранения.

Выясним причину такого поведения. По умолчанию для рабочих процессов кластера серверов 1С выделяется фиксированный диапазон сетевых IP-портов: 1560:1591, что составляет ровно 32 доступных порта. Если процесс выключается (например, по расписанию перезапуска), но операционная система или сам процесс не могут корректно освободить занятый сокет, он зависает в памяти. Когда число таких процессов достигает предела в 32 штуки, менеджер кластера rmngr не может запустить новый рабочий процесс или выделить порт под новое подключение, что приводит к исчерпанию сетевых дескрипторов и аварийному разрыву сессий по ошибке 10054.

Шаг 1. Корректировка параметров перезапуска и завершения процессов кластера

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

Выполним корректировку свойств кластера через консоль администрирования 1С:

  1. Откроем утилиту администрирования серверов 1С:Предприятия.
  2. Перейдем в свойства нужного кластера серверов.
  3. Установим параметр Перезапускать рабочие процессы на более щадящий интервал (рекомендуется не чаще, чем раз в сутки, либо раз в неделю, например, 86400 или 604800 секунд, в зависимости от динамики утечек памяти).
  4. Увеличим параметр Выключенные процессы останавливать через до интервала в 300-600 секунд (5–10 минут). Слишком малое значение (например, 30 секунд) приводит к тому, что процесс принудительно обрывается до того, как успевает корректно закрыть соединения, что оставляет сетевые сокеты в ОС заблокированными.
  5. Проверим параметры Количество ИБ на процесс и Количество соединений на процесс. Если нет строгой необходимости жесткой изоляции, рекомендуется установить эти параметры по умолчанию в значение 0 (или -1), чтобы кластер балансировал нагрузку автоматически без создания избыточных процессов.

Шаг 2. Настройка времени жизни спящих сеансов

Проанализируем пользовательские сессии. Некорректно завершенные клиенты или забытые рабочие места удерживают открытые TCP-сокеты на сервере, мешая процессам завершать свою работу.

  1. В консоли администрирования откроем ветку Информационные базы и перейдем в свойства нужной базы.
  2. Зададим параметр Время засыпания пассивных сеансов (например, 1200 секунд / 20 минут).
  3. Зададим параметр Время завершения спящих сеансов (например, 1800 секунд / 30 минут).
  4. Сохраним настройки, чтобы сервер автоматически принудительно закрывал брошенные пользовательские соединения.

Шаг 3. Расширение пула IP-портов рабочего сервера

Если специфика информационной базы требует параллельной работы большого числа процессов, разберем способ устранения жесткого лимита в 32 процесса.

  1. В консоли администрирования перейдем в раздел Рабочие серверы и откроем свойства текущего сервера.
  2. Найдем поле Диапазоны IP-портов.
  3. Изменим стандартный диапазон 1560:1591 на более широкий, например, 1560:1691.
  4. Перезапустим службу агента сервера 1С (ragent), чтобы применить новые границы доступных сетевых сокетов.

Шаг 4. Настройка стека TCP/IP и сетевого адаптера операционной системы

Посмотрим на системный уровень взаимодействия. По умолчанию в Windows время ожидания проверки активности потерянных TCP-сессий (TCP Keep-Alive) составляет 2 часа. Если клиент отключается нештатно (сбой сети, переход в спящий режим), сервер держит сокет открытым до 120 минут, блокируя выгрузку rphost.

Оптимизируем системные параметры операционной системы:

  1. Откроем редактор реестра regedit на сервере 1С.
  2. Перейдем в ветку реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  3. Создадим или изменим параметр DWORD (32 бита) с именем KeepAliveTime и зададим значение 300000 (в десятичной системе, что соответствует 5 минутам).
  4. Создадим параметр DWORD (32 бита) с именем KeepAliveInterval со значением 1000 (1 секунда).
  5. В свойствах сетевого адаптера сервера (в диспетчере устройств) перейдем на вкладку Дополнительно и отключим функции аппаратной разгрузки сети: Large Send Offload (LSO), IPv4 Checksum Offload, а также отключим энергосберегающие режимы сетевой карты.
  6. На серверах под управлением Windows Server проверим свойства сетевого подключения и при отсутствии явной необходимости отключим протокол IPv6, оставив только IPv4, чтобы исключить конфликты резолвинга локальных адресов.

Шаг 5. Мониторинг технологического журнала и фоновых заданий

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

  1. Настроим сбор технологического журнала с отслеживанием событий EXCP, ATTN, CALL, CONN, PROC.
  2. Проверим журнал регистрации на предмет непрерывно выполняющихся фоновых заданий, которые не завершаются до планового перезапуска процесса.
  3. Разнесем расписание тяжелых ночных обработок и регламентных задач так, чтобы они не пересекались по времени с плановым перезапуском рабочих процессов кластера.
← На главную