Диагностика и оценка скорости работы 1С Предприятие

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

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

С чего начать: локализуем узкое место

Первый вопрос — тормозит всё или одна операция. Ответ меняет весь дальнейший маршрут.

• 🐌 Медленно всё и у всех — смотрите в сторону сервера, СУБД, сети и дисков. Это инфраструктура.
• 🎯 Медленно одна операция (конкретный документ, отчёт, обработка) — проблема в коде или запросе. Это замер производительности и технологический журнал.
• 👤 Медленно у одного пользователя — рабочее место, канал связи, права и отборы в формах списков.

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

Журнал регистрации: быстрый взгляд на длительности

Журнал регистрации (ЖР) — это штатный лог событий базы: кто вошёл, что провёл, где возникла ошибка. Для производительности он полезен колонкой длительности транзакций.

Открыть ЖР в режиме Предприятия можно через Главное меню → Все функции → Журнал регистрации (если пункт «Все функции» не виден, включите его в Сервис → Параметры → Отображать команду "Все функции"). В Конфигураторе — Администрирование → Журнал регистрации.

Что искать:

• 📈 длительные события проведения и записи — отбор по длительности покажет самые тяжёлые операции;
• ❌ ошибки и исключения, которые совпадают по времени с жалобами пользователей;
• 🔁 всплески активности в определённые часы (закрытие месяца , массовые загрузки).

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

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

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

Порядок:

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

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

Типичные находки замера:

• запрос внутри цикла — вместо одного пакетного запроса код дёргает базу сотни раз;
• получение реквизита через точку от ссылки (Ссылка.Владелец.Код) в цикле — каждое обращение это неявный запрос;
• перепроведение зависимых документов, о котором никто не думал.

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

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

ТЖ настраивается файлом logcfg.xml в каталоге conf сервера 1С. В нём задаётся, какие события и свойства логировать и куда складывать файлы. Для диагностики скорости чаще всего собирают:

• DBMSSQL / DBPOSTGRS — обращения к СУБД с текстом SQL и длительностью;
• TLOCK, TDEADLOCK — управляемые блокировки и взаимоблокировки;
• TTIMEOUT — таймауты ожидания на блокировках;
• EXCP — исключения.

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

ТЖ отвечает на вопрос, который недоступен замеру: какой именно SQL-запрос медленный и из-за чего он ждёт — конкуренции за блокировки, долгого чтения или неудачного плана.

Тестирование и исправление информационной базы

Иногда база «тяжелеет» не из-за кода, а из-за накопленных проблем: распухшие таблицы, битые индексы, рассинхронизированные итоги. Для этого есть штатное обслуживание.

Для файловой базы сначала проверяют физическую целостность файла утилитой chdbfl.exe из каталога bin установленной платформы: она открывает файл 1Cv8.1CD и чинит повреждения структуры.

Для любой базы в Конфигураторе есть Администрирование → Тестирование и исправление информационной базы. Полезные для скорости режимы:

• ✅ реиндексация таблиц — перестроить индексы , если база давно не обслуживалась;
• ✅ пересчёт итогов регистров — убрать расхождения, из-за которых отчёты читают лишнее;
• ✅ проверка логической и ссылочной целостности — найти «висящие» ссылки и битые объекты;
• ✅ реструктуризация — пересобрать таблицы по текущей структуре метаданных.

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

Мониторинг сервера и СУБД

Если тормозит всё сразу, причина обычно в ресурсах. Смотреть нужно на трёх уровнях: сервер 1С, сервер СУБД, диски и сеть между ними.

На сервере (Windows — через «Системный монитор»/perfmon, Linux — штатными утилитами) следите за четырьмя показателями:

На стороне СУБД смотрят не «загрузку вообще», а ожидания — на чём запросы простаивают:

• MS SQL Server — статистика ожиданий (sys.dm_os_wait_stats), активные сессии через Монитор активности, тяжёлые запросы по плану выполнения.
• PostgreSQL — расширение pg_stat_statements для самых затратных запросов, pg_stat_activity для текущих сессий, EXPLAIN ANALYZE для разбора конкретного плана.

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

APDEX = (число быстрых операций + число терпимых / 2) ÷ общее число операций.

Операция считается быстрой, если уложилась в целевое время T, терпимой — от T до 4T, неудовлетворительной — дольше 4T. Итог — число от 0 до 1: ближе к 1 (примерно от 0,94) отлично, ниже 0,85 — пользователям уже некомфортно. APDEX хорош тем, что даёт объективную динамику: видно, улучшилась ли реальная работа после правок, а не «кажется, стало быстрее».

Оптимизация запросов и индексы

Разобрав, какой запрос медленный, переходят к почему. На практике большинство проблем со скоростью в 1С — это неоптимальные запросы и нехватка индексов.

Что проверить в первую очередь:

• 🔍 Запрос в цикле. Классическая ошибка: в цикле по строкам таблицы на каждой итерации выполняется отдельный запрос к базе. Решение — один пакетный запрос с временными таблицами до цикла.
• 🔍 Условие по неиндексированному полю. Если отбор идёт по реквизиту, по которому нет индекса, СУБД читает всю таблицу. Нужному реквизиту в Конфигураторе ставят свойство «Индексировать» или «Индексировать с доп. упорядочиванием».
• 🔍 Соединения с подзапросами и виртуальными таблицами. Соединение таблицы с вложенным запросом часто мешает оптимизатору построить хороший план. Выносите промежуточные данные во временные таблицы.
• 🔍 Получение представления и реквизитов через точку в больших выборках — каждая точка это неявное соединение.

Как смотреть план запроса: включите в технологическом журнале сбор текста SQL и его плана для события обращения к СУБД, затем разберите план средствами самой СУБД. В плане ищут полное сканирование таблицы (seq scan / table scan) там, где ожидался поиск по индексу.

Для серверной базы к этому добавляется настройка самой СУБД: актуальная статистика, корректные параметры памяти, регламент перестроения индексов. Эти работы делают уже на стороне администратора СУБД, а не в Конфигураторе.

Нагрузочное тестирование и внешние инструменты

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

• Корпоративный инструментальный пакет (КИП) от 1С. В его составе — Центр управления производительностью (ЦУП) для автоматического сбора и анализа данных технологического журнала и выявления проблемных запросов, и Тест-центр для многопоточного нагрузочного тестирования.
• Тест-центр эмулирует одновременную работу десятков и сотен виртуальных пользователей по заранее записанному сценарию. Так проверяют, при какой нагрузке время операций выходит за целевое и где раньше всего упирается система.

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

Для разовой задачи «почему тормозит вот этот отчёт» внешние пакеты избыточны — хватит замера и технологического журнала. КИП и Тест-центр оправданы на крупных внедрениях, где цена простоя высока и нужно прогнозировать поведение системы под нагрузкой.