Как включить замеры производительности в 1С: пошаговая инструкция

Анализ производительности является критически важным этапом сопровождения любой автоматизированной системы на платформе 1С:Предприятие. Когда пользователи жалуются на медленную работу, зависания отчетов или длительное проведение документов, администратору необходимо получить объективные данные о том, где именно происходит задержка.

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

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

Основные методы диагностики быстродействия 1С

Существует два фундаментально разных подхода к замерам производительности в среде 1С. Первый метод подразумевает использование Технологического журнала (ТЖ), который ведется на стороне сервера приложений. Этот способ наиболее информативен, так как он позволяет анализировать работу системы в многопользовательском режиме без отключения пользователей.

Второй подход — это встроенный режим отладки и замера времени, доступный непосредственно в окне клиента или конфигуратора. Он удобен для локальной проверки конкретного сценария или алгоритма, но менее пригоден для анализа проблем в боевой системе под нагрузкой. Для серьезных исследований администраторы выбирают именно серверный лог.

Выбор метода зависит от архитектуры вашей системы. В файловом варианте базы данных возможности диагностики ограничены клиентскими логами, тогда как клиент-серверный вариант на базе MS SQL или PostgreSQL открывает полный доступ к глубоким метрикам сервера 1С.

⚠️ Внимание: Включение детальных замеров на высоконагруженном сервере может привести к значительному росту размера лог-файлов и снижению общей производительности системы из-за затрат на запись данных.

Настройка Технологического журнала через Конфигуратор

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

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

В открывшемся окне настройки необходимо определить, какие именно события вы хотите отслеживать. Не стоит включать все галочки сразу, так как это создаст огромный объем данных. Для первичной диагностики обычно достаточно выбрать события, связанные с выполнением запросов и блокировками.

• 📊 DBMSSQL или DBMPgSQL — события взаимодействия с СУБД, показывающие время выполнения запросов.
• 🔒 LOCK — информация о захвате и ожидании блокировок данных, что часто является причиной зависаний.
• ⏱️ CALL — фиксация времени вызова общих модулей и внешних обработок.

После выбора необходимых типов событий необходимо указать файл, в который будет вестись запись. По умолчанию используется файл techret.log в каталоге логов сервера. Убедитесь, что у службы сервера 1С есть права на запись в эту директорию.

Ручная правка файла rphost.cfg для сервера 1С

Иногда графический интерфейс недоступен или настройки сбрасываются после перезапуска службы. В таких случаях администраторы прибегают к прямому редактированию конфигурационного файла рабочего процесса. Файл rphost.cfg находится в каталоге установки сервера 1С, обычно в папке bin или в профиле конкретного кластера серверов.

Для включения замеров необходимо добавить или изменить секцию, отвечающую за логирование. Синтаксис файла строгий, и любая ошибка может привести к тому, что рабочий процесс не запустится. Рекомендуется сделать резервную копию файла перед внесением изменений.

<log>
<property name="log" value="file"/>
<property name="file" value="C:\Logs\1C\techret.log"/>
<event>
<property name="kind" value="DBMSSQL"/>
<property name="level" value="error"/>
</event>
</log>

В данном примере мы настраиваем запись только ошибок выполнения запросов к MS SQL. Вы можете менять атрибут level на info или debug для получения более подробной информации, но помните о объеме данных. Параметр kind определяет тип события, и их комбинации позволяют гибко настраивать фильтр.

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

Как найти каталог логов сервера?

По умолчанию каталог технологического журнала находится в папке C:\Program Files\1cv8\srvinfo\reg_1541\logs (цифры могут отличаться в зависимости от порта кластера). Путь можно также посмотреть в оснастке "Администрирование серверов 1С Предприятия".

Анализ логов с помощью утилиты 1CLogReader

После того как замеры были включены и проблемная операция воспроизведена, файл лога необходимо проанализировать. Читать сырой XML-файл технологического журнала вручную крайне неудобно из-за его объема и структуры. Для этих целей существует специализированная утилита 1CLogReader, разработанная сообществом и рекомендованная фирмой 1С.

Эта программа позволяет загружать файл techret.log и представлять данные в виде удобной таблицы с возможностью сортировки по времени выполнения, имени пользователя или типу события. Вы сможете мгновенно увидеть самые долгие запросы, которые тормозят работу системы.

В окне программы обратите внимание на колонку Duration (Длительность). Сортировка по убыванию этого поля сразу покажет вам "узкие места". Часто оказывается, что один конкретный отчет или обработка занимают 90% времени от общего цикла операции.

Тип события	Описание	Влияние на систему
DBMSSQL	Выполнение запроса к базе данных	Высокое (нагрузка на диск и CPU сервера БД)
LOCK	Ожидание снятия блокировки	Критическое (пользователь не может работать)
CALL	Вызов метода или функции	Среднее (нагрузка на процесс 1С)
EXCP	Возникновение исключения	Низкое (если не в цикле)

Использование встроенного профайлера в режиме Предприятия

Если у вас нет доступа к серверу или проблема воспроизводится только на конкретном рабочем месте, можно использовать клиентские средства диагностики. В режиме 1С:Предприятие в меню "Сервис" (или через сочетание клавиш) можно запустить профайлер производительности.

Этот инструмент работает по принципу трассировки стека вызовов. Он показывает дерево вызовов функций и время, затраченное на каждый узел этого дерева. Это идеально подходит для оптимизации кода разработчиками, когда нужно понять, какой именно цикл или вложенный запрос замедляет обработку.

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

• 🚀 Дерево вызовов — показывает иерархию выполнения кода.
• ⏳ Время включительно — время работы функции вместе со всеми вложенными вызовами.
• ⚡ Время исключительно — время, затраченное только на код самой функции без вложений.

Поэтому его использование в боевой базе с большим количеством пользователей не рекомендуется. Это инструмент для локальной отладки.

Интерпретация результатов и поиск узких мест

Получив данные замеров, администратор сталкивается с задачей их правильной интерпретации. Высокое время выполнения запроса DBMSSQL не всегда означает плохой код 1С. Часто причина кроется в отсутствии индексов в базе данных, устаревшей статистике СУБД или нехватке оперативной памяти на сервере.

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

Для анализа SQL-запросов можно скопировать текст запроса из лога и выполнить его непосредственно в среде управления базой данных (например, SSMS для SQL Server). Там вы сможете увидеть план выполнения запроса и понять, почему база данных выбирает неоптимальный путь поиска данных.

⚠️ Внимание: Текст запроса в технологическом журнале может быть параметризован. Для полного понимания логики иногда требуется восстановить исходные значения параметров, подставляемых системой 1С.

Регулярный мониторинг производительности позволяет предотвращать критические ситуации. Настройте автоматическую ротацию логов, чтобы старые файлы удалялись, и диск не переполнялся. Анализ тенденций роста времени отклика поможет спланировать модернизацию оборудования до того, как пользователи начнут массово жаловаться.

Что такое план выполнения запроса?

Это карта, которую строит СУБД перед выполнением запроса. Она показывает, какие индексы будут использованы и в каком порядке будут соединяться таблицы. Неоптимальный план — частая причина тормозов.

Часто задаваемые вопросы (FAQ)

Где именно хранится файл технологического журнала по умолчанию?

Обычно файл techret.log находится в каталоге логов кластера серверов. Путь выглядит примерно так: C:\Program Files\1cv8\srvinfo\reg_[ПОРТ]\logs\. Точный путь зависит от настроек вашего кластера и может быть изменен в конфигурационном файле.

Можно ли включить замеры производительности для файловой базы 1С?

Да, но возможности ограничены. В файловом варианте нет сервера приложений в классическом понимании, поэтому ТЖ ведется на стороне клиента или в специальном режиме. Глубокий анализ блокировок и запросов СУБД доступен только в клиент-серверном варианте.

Как отключить технологический журнал после завершения диагностики?

Необходимо вернуться в настройки Технологического журнала через Конфигуратор и снять галочки с выбранных событий, либо удалить соответствующие секции из файла rphost.cfg и перезапустить службу сервера 1С.

Почему файл лога растет так быстро и занимает все место на диске?

Это происходит, если выбран слишком детальный уровень логирования (например, debug) или включены события, которые происходят тысячи раз в секунду. Всегда используйте фильтры и включайте только необходимые типы событий на короткое время.

Влияет ли включенный ТЖ на скорость работы базы для пользователей?

Да, влияет. Запись каждого события на диск создает дополнительную нагрузку на подсистему ввода-вывода (I/O). На высоконагруженных системах это влияние может быть заметным, поэтому включать замеры следует только на период воспроизведения проблемы.