Как включить замеры производительности в 1С

Замеры производительности — это встроенный механизм платформы 1С:Предприятие и библиотеки стандартных подсистем (БСП), который фиксирует время выполнения участков кода: процедур, функций, запросов и операций с базой данных. Без него поиск «узких мест» превращается в гадание: администратор видит, что отчёт формируется пять минут, но не понимает, где именно теряется время.

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

Ниже разобраны все три сценария: от простого включения замера до настройки регулярного сбора статистики. Инструкции применимы к типовым конфигурациям на управляемых формах (ERP, УТ, КА, БП и другие на базе БСП), а также к самописным решениям.

Какие инструменты замеров есть в 1С и что выбрать

Платформа и типовые конфигурации предлагают несколько уровней измерения, и их часто путают. Замер производительности в конфигураторе показывает время и количество вызовов каждой строки кода в рамках одного сеанса — это инструмент разработчика. Подсистема «Оценка производительности» фиксирует длительность прикладных операций (проведение документа, формирование отчёта) у реальных пользователей — это инструмент администратора.

Технологический журнал (ТЖ) — механизм платформы, который пишет в текстовые файлы все события сервера: запросы к СУБД, вызовы, блокировки, исключения. ЦУП — отдельная конфигурация от фирмы «1С», которая собирает данные ТЖ и показатели СУБД, строит графики и выявляет запросы-долгожители. Это инструменты для серьёзной диагностики нагруженных систем.

Как включить замер производительности в конфигураторе

Этот способ подходит, когда нужно понять, какая строка кода тормозит конкретную операцию. Запустите базу под отладкой: в конфигураторе откройте меню «Отладка» → «Начать отладку» или подключитесь к уже работающему сеансу через «Отладка» → «Подключение». Затем выполните в режиме «Предприятие» проблемную операцию — откройте отчёт или проведите документ.

В момент выполнения операции включите замер: меню «Отладка» → «Замер производительности». С этого момента платформа фиксирует каждый вызов. Дождитесь завершения операции и повторно выберите «Отладка» → «Замер производительности», чтобы остановить сбор. Конфигуратор покажет таблицу: имя модуля, номер строки, количество вызовов, чистое и суммарное время, процент от общего времени.

Сортировка по колонке «Время (сумм.)» сразу показывает самые тяжёлые участки. Обратите внимание на разницу между чистым и суммарным временем: большая разница означает, что процедура сама по себе быстрая, но вызывает тяжёлые вложенные операции.

1. 1
   Запустите отладку или подключитесь к сеансу пользователя
2. 2
   Начните выполнение проблемной операции в режиме «Предприятие»
3. 3
   Включите «Отладка» → «Замер производительности»
4. 4
   Дождитесь завершения операции и выключите замер тем же пунктом меню
5. 5
   Отсортируйте результат по суммарному времени и найдите самые тяжёлые строки

Как включить постоянный сбор замеров в режиме «Предприятие»

В конфигурациях на базе БСП есть штатная подсистема оценки производительности. Откройте раздел «Администрирование» → «Обслуживание» (в некоторых конфигурациях — «Настройки» → «Поддержка и обслуживание») и найдите группу «Оценка производительности». Установите флаг «Выполнять замеры производительности».

После включения система начнёт записывать длительность операций, которые в коде обёрнуты вызовами подсистемы оценки производительности, — в типовых решениях это ключевые действия: проведение документов, формирование отчётов, обмены данными. Накопленные данные смотрятся в отчёте «Оценка производительности» там же, в разделе обслуживания: он показывает список ключевых операций, количество выполнений, среднее и максимальное время, оценку APDEX.

Для периодической выгрузки статистики настройте регламентное задание «Экспорт оценки производительности» — оно выгружает данные в указанный каталог в формате, пригодном для загрузки в ЦУП или внешний анализ. Проверьте расписание задания: по умолчанию оно может быть отключено.

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

Когда подозрение падает на СУБД — медленные запросы, взаимоблокировки, таймауты — включается технологический журнал. На сервере 1С (или на компьютере с файловой базой) создаётся файл logcfg.xml в каталоге conf рядом с исполняемыми файлами платформы. В нём описывается, какие события писать и куда складывать логи.

Минимальная конфигурация для сбора длительных запросов включает события DBMSSQL или DBPOSTGRS (в зависимости от СУБД) с условием по длительности, а также события EXCP для фиксации ошибок. Каталог для логов должен существовать, и у службы сервера 1С должны быть права на запись в него. После создания файла конфигурации журнал начинает писаться автоматически, перезапуск сервера обычно не требуется — платформа подхватывает изменения.

<config xmlns="http://v8.1c.ru/v8/tech-log"><log location="D:\1c_logs" history="24"><event><eq property="name" value="DBMSSQL"/></event><property name="all"/></log><log location="D:\1c_logs" history="24"><event><eq property="name" value="EXCP"/></event><property name="all"/></log></config>

Как настроить ЦУП для регулярного мониторинга

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

После настройки ЦУП регламентными заданиями собирает данные ТЖ, показатели производительности СУБД и статистику ожиданий. Результат доступен в виде дашбордов: общая оценка производительности, топ тяжёлых запросов, динамика по часам. Это позволяет увидеть не разовую проблему, а картину за дни и недели — например, что система тормозит только в часы массового закрытия смен.

ЦУП оправдан для баз с десятками одновременных пользователей и регулярными жалобами на скорость. Для небольшой файловой базы его развёртывание избыточно — достаточно замера в конфигураторе и штатной оценки производительности.

Как проверить, что замеры действительно работают

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

Для технологического журнала проверьте, что в указанном каталоге появились подкаталоги с именами процессов (rphost, rmngr) и файлы с расширением log, внутри которых есть записи с метками времени. Если каталог пуст через несколько минут работы — проверьте путь в logcfg.xml, права службы сервера и корректность XML-файла: ошибка в синтаксисе приводит к тому, что журнал молча не пишется.

Типичные ошибки и ограничения

Самая частая ошибка — включение замера в конфигураторе после того, как операция уже завершилась, или в сеансе без отладки: таблица оказывается пустой, и делается неверный вывод, что «замеры не работают». Замер должен быть активен именно в момент выполнения кода.

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

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

Частые вопросы