Почему в технологическом журнале 1С отображаются только события CONN и как найти реальные задержки производительности

← На главную

При настройке технологического журнала (ТЖ) для поиска узких мест в производительности начинающие специалисты часто сталкиваются с ситуацией, когда вместо ожидаемых «тяжелых» запросов лог заполняется непонятными записями CONN. Разберем детально, почему так происходит, как правильно интерпретировать данные ТЖ и какие настройки необходимо внести, чтобы увидеть реальную картину происходящего на сервере.

Разбор события CONN: ловушка длительности

Рассмотрим ситуацию: вы настроили фильтр в logcfg.xml на события длительностью более 10 секунд и получили список строк, содержащих process=ragent или process=rphost с текстом Outgoing connection closed. Первое впечатление — установка или разрыв соединения занимает критически много времени. Однако это не так.

Выясним причину появления этих записей. В технологическом журнале 1С формат каждой строки выглядит следующим образом: минуты:секунды.микросекунды-длительность. Важно понимать, что для разных типов событий параметр duration (длительность) означает разные вещи. Для события CONN (Connection) зафиксированная длительность — это суммарное время жизни соединения с момента его создания до момента разрыва (или закрытия сессии).

Проанализируем пример из лога: 20:09.697012-787727009,CONN.... Здесь число после дефиса (787727009) — это время в микросекундах (в некоторых версиях — в десятимиллионных долях секунды). Если перевести это в секунды, мы увидим, что соединение просуществовало довольно долго. Поскольку почти любое пользовательское или межпроцессное соединение живет дольше 10 секунд, они все попадают в ваш отчет. Это не ошибка сервера, а штатная фиксация закрытия долгоживущих каналов связи.

Как найти реальные «тормоза» системы

Если наша цель — найти задачи, которые выполняются дольше 10 секунд (запросы, проведение документов, отчеты), нам необходимо сфокусироваться на других событиях. Рассмотрим основные инструменты мониторинга внутри ТЖ:

CALL — это входящие вызовы к серверу 1С. Именно здесь фиксируется время выполнения серверных методов, вызванных клиентом. Если CALL длится долго, значит, именно эта операция (например, нажатие кнопки «Провести») заставила пользователя ждать.
DBMSSQL (или DBV8DBEng для других СУБД) — выполнение прямых запросов к базе данных. Если длительность здесь превышает 10 секунд, проблема в неоптимизированных индексах или структуре запроса в SQL.
SDBL — запросы на внутреннем языке запросов 1С к менеджеру базы данных. Помогает понять, как платформа интерпретирует ваши запросы перед отправкой в СУБД.
SCALL — исходящие вызовы. Например, когда ваш сервер 1С обращается к другому серверу или веб-сервису.

Настройка правильного фильтра в logcfg.xml

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


<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
  <log location="C:\LOGS\PERFORMANCE" history="24">
    <event>
      <eq property="name" value="CALL"/>
      <gt property="duration" value="10000000"/>
    </event>
    <event>
      <eq property="name" value="DBMSSQL"/>
      <gt property="duration" value="10000000"/>
    </event>
    <event>
      <eq property="name" value="SDBL"/>
      <gt property="duration" value="10000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

В данном примере мы явно указываем системе собирать только события CALL, DBMSSQL и SDBL, чья длительность превышает заданный порог. Это позволит отсечь системные уведомления о закрытии соединений CONN и сосредоточиться на коде 1С и запросах.

Инструменты для анализа результатов

Чтение «сырых» текстовых файлов ТЖ — задача трудоемкая. Посмотрим на инструменты, которые значительно упрощают дешифрацию атрибутов событий:

Инструменты разработчика (ИР) — портативный набор обработок, который содержит мощный анализатор технологического журнала. Он позволяет группировать события по процессам, пользователям и контексту исполнения.
Центр управления производительностью (ЦУП) — профессиональное решение от 1С для глубокого мониторинга.
Сервисы анализа логов (например, сервисы Гилева) — облачные или локальные решения, которые автоматически подсвечивают проблемные места в логах.

Важный момент: всегда добавляйте в сбор событие EXCP (Exception) без фильтра по длительности. Ошибки могут происходить мгновенно, но именно они часто являются причиной аварийного завершения процессов rphost или отказов в обслуживании пользователей.

Подведем итог: если вы видите в логах только CONN, значит, ваш фильтр по длительности слишком широк для этого типа событий. Сконцентрируйтесь на CALL и DBMSSQL, используйте специализированные инструменты для анализа, и вы сможете увидеть реальные причины деградации производительности вашей системы.