Как выполнить замер производительности 1С 8.3

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

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

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

Подготовка инфраструктуры и выбор методики

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

Важно обеспечить изолированность теста. Если вы проводите замеры на рабочей базе в рабочее время, результаты будут «смазаны» фоновыми задачами других сотрудников. Идеальный вариант — использование копии базы на тестовом сервере. Если это невозможно, согласуйте время проведения работ с руководством, так как включение детального логирования может незначительно снизить общую скорость работы системы.

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

⚠️ Внимание: Никогда не включайте режим подробного логирования (уровень debug) на продуктивном сервере без острой необходимости и мониторинга места на диске. Это может привести к переполнению раздела и остановке службы 1С.

Настройка Технологического Журнала (ТЖ)

Основным инструментом для глубокого анализа является Технологический журнал. Это механизм платформы, который позволяет записывать в текстовые файлы подробную информацию о событиях, происходящих внутри процессов rphost и rmngr. Правильная настройка ТЖ — это 80% успеха в диагностике.

Для активации журнала необходимо отредактировать файл logcfg.xml. Он может находиться в каталоге установки платформы (глобальная настройка) или в папке конкретной информационной базы (локальная настройка). Рекомендуется использовать локальную настройку, чтобы не затрагивать другие базы на сервере. Путь к файлу обычно выглядит так: C:\ProgramData\1C\1Cv8\\logcfg.xml.

Структура файла XML должна содержать описание потоков и событий, которые вы хотите отследить. Для замера производительности наиболее важными являются события вызова методов, выполнения запросов к СУБД и блокировок. Ниже приведен пример минимально необходимой конфигурации для отслеживания длительных операций.

<config>
<log>
<ne event="call" />
<ne event="dbcall" />
<ne event="lock" />
<ne event="excp" />
</log>
</config>

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

Использование встроенных инструментов отладки

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

Для запуска замера в режиме предприятия можно использовать обработку «Замер производительности», которая часто поставляется в составе типовых конфигураций или доступна в репозиториях ИТС. Она позволяет зафиксировать время начала и конца операции, а также количество обращений к базе данных. Это дает первичное понимание масштаба проблемы.

Если вы работаете в конфигураторе, можно воспользоваться меню Отладка → Профилирование. После запуска вы получите отчет, в котором функции отсортированы по времени исполнения. Обратите внимание не только на собственное время функции, но и на полное время, включающее вызовы других методов.

• 🔍 Call — фиксирует вход и выход из функций 1С, показывая стек вызовов.
• 💾 DBCall — записывает все обращения к СУБД, что критично для поиска медленных запросов.
• 🔒 Lock — отображает установки и снятие блокировок, помогая найти взаимоблокировки (deadlocks).
• ⚡ Excp — логирует возникновение исключительных ситуаций, которые могут тормозить систему.

Анализ этих данных требует внимания к деталям. Часто одна функция вызывает другую тысячи раз в цикле, и именно суммарное время этих вызовов создает нагрузку. Не игнорируйте количество обращений: даже быстрый запрос, выполненный миллион раз, «повесит» сервер.

Анализ логов и выявление узких мест

Самая сложная часть процесса — это чтение и интерпретация полученных логов. Файлы технологического журнала имеют специфический формат, и читать их вручную в блокноте при больших объемах данных невозможно. Для этого существуют специализированные утилиты, такие как 1C:LogAnalyzer или сторонние скрипты на Python/PowerShell.

При анализе обращайте внимание на события с большим временем выполнения. Нормальное время выполнения простого запроса измеряется миллисекундами. Если вы видите запрос, который выполняется 2-3 секунды и более, это кандидат на оптимизацию. Особое внимание уделите запросам, выполняемым внутри циклов.

Также критически важно анализировать блокировки. Если в логах вы видите цепочку событий lock, которая не разрешается длительное время, значит, один пользователь держит объект, а другие ждут его освобождения. Это часто случается при проведении документов в одном журнале несколькими пользователями одновременно.

Тип события	Описание	Критичность	Действие
DBCall	Обращение к базе данных	Высокая	Оптимизация текста запроса, индексы
Call	Вызов метода 1С	Средняя	Рефакторинг кода, устранение циклов
Lock	Установка блокировки	Критическая	Анализ транзакций, изменение логики
Mngr	Работа менеджера кластера	Низкая	Настройка балансировки

Почему логи такие большие?

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

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

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

Другая частая ошибка — неправильная интерпретация времени. Пользователи часто путают время отклика интерфейса и время выполнения запроса на сервере. Задержка может быть вызвана медленным каналом связи, слабым клиентским ПК или сетевыми задержками, а не работой самой платформы 1С.

Также стоит упомянуть ошибку «замер на грязной базе». Если в базе данных фрагментированы индексы или отсутствует статистика СУБД, результаты замера покажут низкую производительность, которая устраняется не изменением кода, а регламентными процедурами обслуживания базы данных (Reindex, Update Statistics).

⚠️ Внимание: Параметры производительности зависят от версии платформы 1С и версии СУБД. То, что было медленно в версии 8.3.10, может работать быстро в 8.3.24 благодаря оптимизациям ядра. Всегда сверяйтесь с релиз-нотами.

Оптимизация на основе полученных данных

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

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

Не забывайте про аппаратную часть. Если анализ показывает, что процессор загружен на 100% при выполнении вычислений в коде 1С, а запросы быстрые, то программной оптимизацией ситуацию не исправить. Здесь поможет только масштабирование сервера или распределение нагрузки по дополнительным рабочим процессам rphost.

Нужно ли останавливать базу данных для замера производительности?

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

Где хранятся файлы технологического журнала по умолчанию?

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

Может ли включенный ТЖ замедлить работу 1С?

Да, запись логов создает дополнительную нагрузку на дисковую подсистему и процессор. В режиме детального логирования (события call и dbcall) падение производительности может достигать 10-20%.

Как часто нужно проводить замеры производительности?

Регулярные замеры не требуются. Это процедура «по факту возникновения проблем» или перед внедрением крупных обновлений конфигурации, чтобы убедиться, что новая функциональность не ухудшила быстродействие.