Разброс времени на разных компьютерах может приводить к обрыву соединений | | Ускоряем 1С:Предприятие

Conn | | ускоряем 1с:предприятие

Важно знать, что все процессы платформы взаимодействуют между собой посредством заранее установленных TCP-соединений.

Такие события фиксируются в технологическом журнале. Даже если никто не работает в системе, там постоянно будут идти события – PROC и CONN.

Событие CONN – это установка или разрыв клиентского соединения с сервером.
Тут под клиентом имеется в виду не пользователь, а клиент со стороны инициатора соединения. В принципе, при любой установке TCP-соединения – что тонкого клиента с рабочим процессом, что рабочего процесса с rmngr – будет фиксироваться событие CONN.

В событиях CONN мы тоже можем видеть свойство Txt, где в произвольной форме,  указываются различные интересные сообщения.

Обычно первое событие CONN, в свойстве Txt которого указано Accepted. Событие говорит о том, что рабочий процесс (process=rphost), акцептовал некое TCP-соединение.

Также могут быть события с Txt=Connected и которых видно, что процесс успешно установил TCP-соединение.

Если на событиях CONN много количественно Accepted и Connected, то это свидетельствует о проблемах связанных с установкой/разрывами соединений.

В финале, когда соединение TCP закрывается, тоже выводится событие CONN и оно уже имеет длительность, показывая длительность удержания TCP-соединения между процессами.

Также интересный вариант использования событий CONN – это отслеживать моменты, когда пользователи, заходят в систему под своей доменной учетной записью, но работают в 1С под другим именем пользователя. Когда клиент (тонкий или толстый) подключается к рабочему процессу, будет зафиксировано событие CONN – установка соединения. В этом событии будет передано не имя пользователя, а имя его доменной учетной записи. Это позволит точно узнать пользователя, который мог выполнять в системе странные операции под другим пользователем.

:/>  Изоляция графов аудиоустройств Windows 10 грузит процессор: 4 способа отключения

В событиях CONN выводится информация подсистемы отслеживания разрывов соединений в кластере. Для таких событий CONN в свойстве Txt будет указано ‘Ping direction statistics’. С помощью этих событий можно собирать полезную информацию, чтобы понять, есть ли у нас проблемы с сетью между компонентами кластера. Подобные CONN выводятся в лог раз в 10 секунд и несут в себе накопленную статистику.

В свойствах таких событий есть следующее:

address – ip адрес для которого выполняется сбор статистики.

pingTimeout и pingPeriod — таймаут и период опроса в мс. По умолчанию, в платформе стоит возможность сетевого таймаута на 5 секунд. Например, если рабочий процесс не ответит агенту сервера за 5 секунд, то будет считаться, что он потерялся.

Свойство packetsTimeOut, помогает сделать вывод о качестве сетевого взаимодействия между компонентами кластера. При нормальной работе, конечно, никаких таймаутов быть не должно. Я здесь специально нашел пример, когда у нас произошла проблема, и процесс rmng фиксировал потери – пять таймаутов.

Свойство packetsLost показывает потери пакетов (потеряно четыре пакета – packetsLost=4). Эту информацию довольно сложно интерпретировать, потому что статистика отслеживается в рамках скользящего 10-секундного окна. Пакеты могут оцениваться как потерянные в текущем окне статистики, но в следующем 10-секундном окне на них могут быть получены ответы.

Свойство packetsLostAndFound показывает количество пакетов, которые были отправлены в одном окне, а пришли в другом. Оно несколько помогает интерпретировать свойство packetsLost.

avgResponseTime и maxResponseTime – эти свойства показывают сетевые задержки.

Восстановление системных настроек по умолчанию

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

:/>  Cool and funniest browser cursors - use our large free collection or upload your own.

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

В некоторых ситуациях это может стать проблемой при работе в смешанных средах IPv4 и IPv6: TechNet Forums – Windows 7 Networking – How to change default TCP/IP to v4?

Поэтому, если в такой ситуации нам потребуется вернуть исходную конфигурацию, используемую по умолчанию в Windows Server 2022 R2, то можем выполнить удаление созданным нами ранее политик. При их удалении будут автоматически восстановлены настройки по умолчанию. Например, в нашем случае достаточно будет выполнить команду удаления одной ранее добавленной политики:

netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96

Дополнительные источники информации:

Понижение приоритета ipv6

В операционных системах Windows начиная с Windows Vista в конфигурации по умолчанию у протокола IPv6 имеется приоритет над протоколом IPv4. В некоторых ситуациях наличие этого приоритета может проявляться даже несмотря на то, что в привычном всем графическом интерфейсе настроек сетевого подключения протокол IPv6 выключен

Например, если мы, находясь на хосте, с помощью утилиты ping попробуем проверить доступность хоста по его же имени или с использованием имени localhost, то увидим, что по умолчанию используется проверка доступности по IPv6 адресу

Разброс времени на разных компьютерах может приводить к обрыву соединений

Причиной перезапуска процессов может являться изменение системного времени. Из-за этого процесс rmngr фиксирует исчерпание таймаута ожидания принга от рабочего процесса и считает рабочий процесс пропавшим. Это происходит например если у вас включена синхронизация с NTP сервером, и периодически происходит значительная корректировка времени. Это можно обнаружить в журнале событий Windows по событию от Kernel-General об изменении времени  Event Viewer — группа Windows Log — журнал System — отбор (Filter Current Log) по Event Sources = Kernel General и Event ID = 1 типа такого:
The system time has changed to ‎2022‎-‎01‎-‎30T13:31:54.401000000Z from ‎2022‎-‎01‎-‎30T13:31:49.686072200Z.
Change Reason: An application or system component changed the time.

:/>  CMD команды

Запускается новый рабочий процесс сервера 1С, а старый завершается. Тайм-аут по умолчанию равен 5 секундам.
Пользователями это воспринимается как массовое подвисание.

Для его изменения можно запустить ragent с параметрами, например, -pingperiod 3000 -pingtimeout 15000.

Оставьте комментарий

Adblock
detector