Технологический анализ в 1С 8: что это и как его провести

Технологический анализ в 1С 8 — это комплекс действий по диагностике работы информационной базы: сбору и разбору технологического журнала, замерам производительности, анализу запросов к СУБД, блокировок и ошибок платформы. Его цель — найти конкретные причины медленной работы, зависаний, взаимоблокировок и аварийных завершений, а не гадать, «кто виноват»: сервер, сеть, код или пользователи.

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

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

Из чего состоит технологический анализ

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

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

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

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

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

Настройка технологического журнала

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

Типовой минимальный набор для диагностики производительности: события DBMSSQL (или DBPOSTGRS для PostgreSQL) с порогом длительности, EXCP для исключений, TLOCK, TTIMEOUT и TDEADLOCK для блокировок. Порог длительности задаётся в микросекундах: значение 1000000 соответствует одной секунде — события быстрее порога в журнал не попадут.

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

Ограничивайте объём записи: параметр history задаёт время хранения логов в часах, без него каталог будет расти до заполнения диска. Для первичной диагностики достаточно 24–72 часов записи, захватывающих периоды пиковой нагрузки.

Разбор результатов: что искать в логах

Логи ТЖ пишутся в файлы формата .log, разбитые по часам и процессам (rphost, ragent, rmngr). Читать их вручную тяжело, поэтому применяют специализированные инструменты разбора или хотя бы поиск по ключевым словам: Duration, TDEADLOCK, EXCP.

Для событий запросов к СУБД ключевые поля — длительность (Duration), текст запроса (Sql) и контекст (Context — какой код конфигурации инициировал запрос). Если один и тот же запрос всплывает многократно с большой длительностью — это кандидат на оптимизацию: индекс, переписывание запроса, изменение логики кода.

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

Замеры производительности и анализ запросов

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

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

1. 1
   Зафиксируйте симптом: какая операция, у кого, в какое время, сколько длится
2. 2
   Проверьте загрузку сервера СУБД и кластера 1С в момент проблемы
3. 3
   Сделайте замер производительности на воспроизводимой операции
4. 4
   Если проблема плавающая — включите ТЖ с фильтрами на длительные запросы и блокировки
5. 5
   Найдите запрос или участок кода с максимальной длительностью
6. 6
   Проанализируйте план запроса: сканирования вместо поиска по индексу, нехватка индексов
7. 7
   Внесите точечное исправление и повторите замер под сопоставимой нагрузкой

Типичные ошибки при проведении анализа

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

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

Ограничения и когда привлекать специалистов

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

Рискованные действия, которые не стоит выполнять на рабочей базе без резервной копии и плана отката: массовое пересоздание индексов, изменение схемы данных, правка запросов в типовых модулях, смена настроек СУБД. Любое изменение проверяйте сначала на копии базы с сопоставимым объёмом данных — на тестовой базе в 100 МБ проблема боевой базы в 200 ГБ просто не воспроизведётся.

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