Замеры статистики в 1С: что это и как с ними работать

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

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

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

Что именно фиксируют замеры статистики

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

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

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

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

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

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

Где смотреть результаты замеров

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

При анализе полезно смотреть не только среднее время, но и максимальное. Операция со средним временем 2 секунды и максимальным 120 секунд — признак блокировок или конкуренции за ресурсы, а не медленного кода как такового. Если же все замеры равномерно высокие, проблема скорее в алгоритме, запросе или нехватке индексов.

Замеры на уровне платформы: технологический журнал

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

ТЖ настраивается через файл logcfg.xml, который размещается в каталоге conf сервера 1С. В нём задают, какие события фиксировать: длительные запросы к СУБД (DBMSSQL, DBPOSTGRS), блокировки (TLOCK, TDEADLOCK), длительные вызовы (CALL), исключения (EXCP). По умолчанию ТЖ выключен, и включать его «на всякий случай» с максимальной детализацией не стоит — объём логов растёт быстро и сам по себе замедляет дисковую подсистему.

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

Пример выше включает запись всех обращений к MS SQL Server с хранением логов 24 часа. Для продуктивной базы лучше сужать фильтр — например, фиксировать только запросы длиннее заданного порога через событие с условием по duration.

Как интерпретировать замеры и находить причину

Типичная схема диагностики выглядит так: замеры показывают проблемную операцию → технологический журнал показывает конкретный запрос или блокировку внутри неё → план запроса в СУБД показывает, чего не хватает (индекса, актуальной статистики) или где лишний перебор данных.

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

Ограничения и типичные ошибки при работе с замерами

Замеры фиксируют только те операции, для которых предусмотрены ключевые точки измерения. Если проблема находится в доработанном коде без замеров, в отчёте она не появится — разработчику нужно добавить ключевую операцию вручную через обращение к менеджеру оценки производительности.

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