Диагностика быстродействия 1С: с чего начать и чем мерить

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

Инструменты диагностики производительности делятся на три уровня: код конфигурации, сервер приложений 1С и СУБД. Ниже — какой из них включать в каждом случае, какие цифры снимать и как их читать. Все пути приведены для платформы 8.3 в интерфейсе «Такси».

Встроенный замер в конфигураторе: быстрый способ найти узкое место

Самый дешёвый инструмент встроен в платформу и не требует прав администратора кластера. Открывается он в конфигураторе: Отладка → Замер производительности.

Порядок простой:

1. В конфигураторе выполните Отладка → Замер производительности.
2. Подключитесь к сеансу, где воспроизводится проблема (кнопка подключения к предмету отладки).
3. Нажмите «Начать замер» и повторите медленное действие в пользовательском сеансе — открытие формы, проведение документа, формирование отчёта.
4. Остановите замер.

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

Этот способ отвечает на вопрос «где в коде тратится время», но не видит блокировок и нагрузки на диск. Для них нужны инструменты уровнем ниже.

APDEX и тест Гилёва: как получить объективную цифру

Чтобы спорить о быстродействии не на уровне «кажется, стало медленнее», нужна повторяемая метрика. Их две.

Оценка производительности (APDEX) — подсистема библиотеки стандартных подпрограмм. Включается в разделе Администрирование (пункт «Оценка производительности» появляется после включения соответствующей настройки). После включения платформа фиксирует время ключевых операций, которые заданы в справочнике, и по ним считает индекс APDEX от 0 до 1.

Формула простая: операции делятся на «уложившиеся в целевое время», «терпимые» (до четырёх целевых) и «провальные». Индекс = (число хороших + половина терпимых) / общее число замеров. Чем ближе к единице — тем лучше. Для каждой операции задают своё целевое время: открытие списка — доли секунды, тяжёлый отчёт — десятки секунд.

Тест Гилёва (TPC-1C) — бесплатная внешняя обработка, которая прогоняет синтетический сценарий и выдаёт одно число — условные баллы («попугаи»). Он не ищет причину, но даёт базовую точку: запустили до изменений, запустили после — видно, помогло или нет. Полезен и для сравнения серверов перед покупкой.

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

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

Настраивается ТЖ файлом logcfg.xml. Для серверной базы он кладётся в папку conf каталога установки платформы (например, C:\Program Files\1cv8\conf\logcfg.xml) и действует на все процессы кластера. Перезапуск службы не нужен — платформа подхватывает файл в течение минуты.

Минимальный конфиг, который ловит запросы к СУБД дольше секунды:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\v8log" history="4">
        <event>
            <eq property="name" value="DBMSSQL"/>
            <ge property="duration" value="1000000"/>
        </event>
        <property name="all"/>
    </log>
</config>

Здесь duration указывается в микросекундах, то есть 1000000 ≈ 1 секунда, а history="4" хранит журнал 4 часа. Какие события обычно собирают:

• 🐘 DBMSSQL, SDBL — запросы к СУБД и язык запросов платформы: ищем долгие.
• 🔒 TLOCK, TTIMEOUT, TDEADLOCK — установка управляемых блокировок, таймауты и взаимоблокировки.
• 💥 EXCP — исключения, в том числе фоновые падения.
• 📞 CALL, SCALL — серверные вызовы: видно, что инициировало долгую операцию.

Технологический журнал без фильтра забивает диск гигабайтами за минуты. Всегда ставьте отбор по duration или по конкретному событию и ограничивайте history.

Сервер приложений 1С: процессы rphost, rmngr и ragent

На серверной базе за работу отвечают три типа процессов, и у каждого своя роль при диагностике:

• ragent — агент сервера, точка входа, слушает порт 1540. Через него работает консоль администрирования.
• rmngr — менеджер кластера, порт 1541. Ведёт список сеансов и распределяет нагрузку.
• rphost — рабочий процесс, в нём исполняется код и живут сеансы. Портов у рабочих процессов несколько, диапазон задаётся в свойствах рабочего сервера.

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

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

Профилирование СУБД: SQL Server и PostgreSQL

Если ТЖ показал, что время уходит в событии DBMSSQL, дальше копают на стороне СУБД. Инструменты зависят от сервера.

Для Microsoft SQL Server:

• Расширенные события (Extended Events) — штатная замена устаревшего SQL Server Profiler, грузит сервер меньше.
• Хранилище запросов (Query Store) — копит статистику по планам и регрессиям, удобно ловить «вчера работало, сегодня нет».
• Динамические представления (DMV) sys.dm_exec_query_stats, sys.dm_os_wait_stats — топ тяжёлых запросов и типы ожиданий.
• Монитор активности (Activity Monitor) в SSMS — быстрый взгляд на текущую нагрузку.

Для PostgreSQL (включая сборки 1С):

• Расширение pg_stat_statements — накопительная статистика по запросам: суммарное время, число вызовов, среднее.
• Модуль auto_explain и параметр log_min_duration_statement в postgresql.conf — логирование планов долгих запросов.
• Представление pg_stat_activity — что выполняется прямо сейчас.
• Утилита pgBadger — сводный отчёт по логам.

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

Системные счётчики через PerfMon

Чтобы отделить «1С медленная» от «железо не тянет», на Windows снимают счётчики производительности системным монитором (perfmon.exe). Он есть в любом Windows Server 2016 и новее, данные пишутся в набор сборщиков по расписанию.

Базовый набор счётчиков для сервера 1С и СУБД:

Счётчики снимают не точечно, а интервалом хотя бы в полчаса под реальной нагрузкой — иначе провал видно, а причину нет. Диск почти всегда оказывается первым подозреваемым для баз 1С — именно задержки ввода-вывода чаще всего превращаются в «тормоза» на стороне пользователя.

Блокировки и взаимоблокировки

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

В технологическом журнале их видно по событиям:

• TLOCK — установка и снятие управляемой блокировки.
• TTIMEOUT — сеанс не дождался блокировки и упал по таймауту.
• TDEADLOCK — взаимоблокировка: два сеанса ждут ресурсы друг друга, платформа разрывает одного.

По этим событиям в ТЖ видно, какой сеанс кого ждал, какие ресурсы (таблицы и их диапазоны) конфликтовали и в каком коде это случилось. На стороне SQL Server граф взаимоблокировки дополнительно собирается расширенными событиями.

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

Сводная таблица: инструмент под задачу

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

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