Как выполнить технологический анализ в 1С

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

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

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

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

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

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

Настройка logcfg.xml: какие события включать

Файл logcfg.xml размещается в каталоге конфигурации сервера 1С (для Windows это обычно подкаталог conf в каталоге установки сервера, для Linux — каталог конфигурации службы сервера). Внутри файла задаются события (event), условия отбора (property) и каталог размещения логов (location). Если файл содержит ошибки синтаксиса XML, платформа его проигнорирует, и логи не появятся — это одна из самых частых причин «пустого» результата.

Минимальный рабочий набор для анализа производительности включает события вызовов СУБД (DBMSSQL для Microsoft SQL Server, DBPOSTGRS для PostgreSQL, DBORACLE для Oracle), события исключений (EXCP), взаимоблокировок (DEADLOCK, TDEADLOCK, TLOCK, TTIMEOUT) и длительных операций. Для каждого события можно задать отбор по длительности, чтобы не писать миллионы коротких вызовов.

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

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

Сбор событий: как воспроизвести проблему

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

1. 1
   Разместите logcfg.xml с нужными событиями в каталоге конфигурации сервера и убедитесь, что в указанном каталоге начали создаваться файлы логов.
2. 2
   Попросите пользователя воспроизвести проблемную операцию, зафиксируйте точное время начала и окончания.
3. 3
   Дождитесь завершения операции и скопируйте файлы логов в отдельный каталог для анализа.
4. 4
   Отключите или сократите набор событий в logcfg.xml, чтобы не накапливать лишние данные.
5. 5
   Проверьте, что в логах есть события за зафиксированный интервал времени — иначе анализ будет бесполезен.

Если проблема плавающая и воспроизвести её по запросу нельзя, оставьте ТЖ включённым с узким набором событий (например, только EXCP и DEADLOCK) и увеличенным сроком хранения. Такие события пишутся редко и почти не влияют на производительность, зато позволят поймать момент сбоя.

Анализ собранных данных: на что смотреть в первую очередь

Файлы технологического журнала — это текстовые файлы с событиями в формате «минуты:секунды.микросекунды-длительность,ИмяСобытия,процесс,свойства». Разбирать их вручную в текстовом редакторе тяжело: на загруженной системе за час накапливаются сотни тысяч строк. Практичный подход — фильтровать по длительности и по контексту.

Начните с поиска самых длительных событий в интервале воспроизведения. В событиях DBMSSQL длительность указана в микросекундах; события с длительностью в сотни тысяч и миллионы микросекунд (сотни миллисекунд и секунды) — основные кандидаты на проблему. Для каждого такого события смотрите текст запроса (свойство Sql), контекст исполнения (Context) и имя пользователя (Usr).

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

Анализ запросов и блокировок

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

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

Дополнительные инструменты анализа

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

На уровне СУБД полезны штатные средства мониторинга: динамические административные представления в MS SQL Server, представления статистики в PostgreSQL. Они показывают самые ресурсоёмкие запросы за период, ожидания, состояние индексов. На уровне ОС — счётчики производительности диска, памяти и процессора: иногда «тормоза 1С» оказываются нехваткой оперативной памяти или медленным диском под базой.

Типичные ошибки и ограничения

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

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

Проверка результата после исправлений

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

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