Диагностика скорости 1С 8.3: чем измерять тормоза

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

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

С чего начать: воспроизвести проблему и зафиксировать цифру

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

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

Полезно сразу разделить, где теряется время:

• 🖥️ клиент — тяжёлая форма, много элементов, медленный канал до сервера;
• ⚙️ сервер приложений — исполнение кода, компоновка отчёта, фоновые задания;
• 🗄️ СУБД — долгие запросы, нехватка памяти под кэш, блокировки;
• 🔌 инфраструктура — сеть, диск, виртуализация.

Эта модель «клиент → сервер → СУБД → железо» задаёт маршрут диагностики. Инструменты ниже закрывают каждый из слоёв.

Журнал регистрации: кто и что запускал

Журнал регистрации — встроенный лог событий базы: входы и выходы пользователей, проведение документов, ошибки, запуск регламентных заданий. Открывается в режиме 1С:Предприятие через Главное меню → Все функции → Журнал регистрации, в конфигураторе — через меню Администрирование → Журнал регистрации.

Для диагностики производительности журнал даёт две вещи. Первая — отбор по интервалу времени: если тормоза начинаются в 10:00, смотрите, что именно происходит в базе в эти минуты (массовое перепроведение, закрытие месяца , выгрузка). Вторая — фильтр по пользователю и событию: видно, чьи сеансы создают нагрузку.

Настройте отбор по полям «Пользователь», «Время», «Событие». События об ошибках и завершении работы с исключением часто объясняют, почему операция «подвисла».

Чего журнал регистрации не покажет: он не раскладывает время внутри операции по запросам и строкам кода. Для этого нужны технологический журнал и замер производительности.

Технологический журнал: медленные запросы и блокировки

Технологический журнал (ТЖ) — главный инструмент глубокой диагностики. Он записывает низкоуровневые события платформы: обращения к СУБД, вызовы серверного кода, ожидания на управляемых блокировках, исключения.

Включается ТЖ не в интерфейсе, а конфигурационным файлом logcfg.xml, который кладут в каталог conf установленной платформы (на сервере — в каталоге соответствующей версии 1cv8). В файле указывают, какие события писать, с какой фильтрацией и куда складывать логи.

Для поиска тормозов важны эти события:

Самый частый сценарий: отбираете события DBMSSQL с большой длительностью — и видите конкретный текст запроса, который читает лишнее. Дальше запрос оптимизируют: добавляют индекс, убирают соединение с виртуальной таблицей, переносят отбор в условие.

Второй частый сценарий — периодические зависания на блокировках. В событии TLOCK виден объект, на котором операция ждала, а в TDEADLOCK — две операции, заблокировавшие друг друга. Сопоставив их по времени с журналом регистрации, вы находите пару документов или заданий, которые конфликтуют, и разводите их по времени либо меняете порядок захвата данных.

Фильтр по длительности в logcfg.xml экономит силы: нет смысла писать все события подряд, достаточно собрать запросы дольше заданного порога (например, от одной секунды). Так лог остаётся читаемым, а в него попадает только то, что действительно тормозит.

Логи ТЖ — это текстовые файлы, которые разбирают либо вручную, либо утилитами разбора (парсерами). Для разовой задачи хватает поиска по длительности в тексте лога; для регулярного анализа используют специализированные инструменты сбора статистики.

Оценка производительности и показатель АПДЕКС

В типовых конфигурациях на БСП есть подсистема оценки производительности. Она замеряет время ключевых операций (проведение, открытие формы, отчёт) и считает интегральный показатель — АПДЕКС (APDEX). Это число от 0 до 1: чем ближе к единице, тем чаще операции укладываются в целевое время.

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

Ценность метода — в объективности. Вместо «кассирам кажется, что медленно» вы получаете цифру: ключевая операция «Проведение чека» имеет АПДЕКС 0,6 при целевом времени 1 секунда. Это и есть приоритет для оптимизации.

Порядок работы с оценкой производительности:

1. Включить замеры в настройках базы.
2. Задать для ключевых операций целевое время (сколько секунд считается приемлемым).
3. Дать системе поработать несколько дней, накопить данные.
4. Построить отчёт по АПДЕКС и отсортировать операции по худшим показателям.
5. Взять верхние строки в работу — именно они бьют по пользователям сильнее всего.

Замер производительности в конфигураторе: ищем строку кода

Когда понятно, что время уходит на сервере приложений (а не в СУБД), помогает замер производительности из конфигуратора. Запускается он через меню Отладка → Замер производительности, после чего вы выполняете медленную операцию в режиме 1С:Предприятие под отладкой.

Результат — таблица по строкам кода: сколько раз каждая строка выполнялась, сколько заняла по чистому и по полному времени. Сразу видно процедуру или цикл, которые съедают секунды: например, запрос внутри цикла, который следовало вынести наружу, или повторное обращение к серверу на каждой итерации.

Это точечный инструмент для разработчика. Он не заменяет ТЖ (тот смотрит на СУБД), но отвечает на вопрос «какой именно код тормозит», когда проблема в алгоритме, а не в запросе.

Мониторинг операционной системы и СУБД

Если встроенные инструменты показывают, что сервер «ждёт» ресурсы, пора смотреть за пределы 1С. Здесь работают средства операционной системы и СУБД.

На Windows Server базовый набор даёт системный монитор perfmon. Ключевые счётчики:

• процессор — % Processor Time: устойчивая загрузка под 90–100 % говорит о нехватке ядер;
• память — доступная оперативная память (Available MBytes): если свободной почти нет и идёт активная подкачка, серверу тесно;
• диск — длина очереди к диску и время отклика: длинная очередь к диску под базой данных означает, что диск не успевает.

Для СУБД смотрят собственные показатели сервера баз данных. Для Microsoft SQL Server это, например, запросы в секунду и время жизни страниц в кэше (Page Life Expectancy): маленькое значение указывает на нехватку памяти под кэш данных. Для детального анализа запросов на стороне СУБД применяют трассировку (в SQL Server — расширенные события, Extended Events).

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

Как читать показатели на практике. Устойчивая загрузка процессора под 90–100 % в момент тормозов — сигнал, что ядер не хватает именно под эту нагрузку (а не «вообще мало»). Нулевая свободная память вместе с активной подкачкой на диск — машине тесно, и первым делом поднимают оперативную память, а не частоту процессора. Длинная очередь к диску под файлами базы данных означает, что узкое место — дисковая подсистема; здесь помогает перенос базы на быстрый накопитель, а не апгрейд процессора. Смысл в том, чтобы сопоставить момент тормоза с конкретным счётчиком, а не менять железо наугад.

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

Как свести данные вместе и найти узкое место

Отдельные цифры сами по себе бесполезны — важно их сопоставить. Рабочая последовательность диагностики такая:

1. Зафиксировать симптом и время медленной операции (нулевая точка).
2. Посмотреть журнал регистрации в момент проблемы — что ещё происходило в базе.
3. Снять ресурсы ОС через perfmon — упирается ли сервер в процессор, память или диск.
4. Если ресурсы свободны — включить ТЖ и найти долгие DBMSSQL или ожидания TLOCK.
5. Если тормозит код, а не запрос — сделать замер производительности в конфигураторе.
6. Устранить одну причину и повторить замер той же операции.
7. Сравнить с нулевой точкой — стало ли быстрее.

Главное правило — менять по одному и перепроверять. Если включить индекс, переписать запрос и добавить памяти одновременно, вы не поймёте, что именно сработало, и в следующий раз будете гадать заново.

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