Технологический анализ производительности 1С: Предприятие

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

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

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

Подготовка окружения и настройка сервера

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

Для включения журнала требуется отредактировать файл конфигурации кластера серверов ragent.ini. Этот файл обычно находится в каталоге установки сервера 1С, в подпапке conf. Если вы работаете в среде Linux, путь может выглядеть как /etc/opt/1C/1Cv8/ragent.ini, а в Windows — C:\Program Files\1cv8\conf\ragent.ini. Вносить изменения в этот файл необходимо с правами администратора или суперпользователя.

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

⚠️ Внимание: Никогда не включайте логирование событий уровня CALL или EXCP на работающей базе в час пик без предварительной оценки объема данных. Это может привести к отказу сервиса из-за нехватки дискового пространства или IOPS.

После внесения изменений в ragent.ini необходимо перезапустить службу агента сервера 1С. В Windows это делается через snap-in «Службы» (служба 1С:Предприятие 8.3 Сервер), а в Linux командой systemctl restart srv1cv83. Только после перезапуска новые настройки вступят в силу, и сервер начнет писать файлы технологического журнала в указанную папку.

Конфигурация правил логирования

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

Рассмотрим базовый пример настройки для анализа медленных запросов. Нам нужно перехватывать события выполнения запросов к базе данных, которые занимают слишком много времени. Для этого используется событие DBMSSQL (для MS SQL) или DBMPG (для PostgreSQL). В конфигурации это выглядит как присвоение параметра =info или =debug в зависимости от требуемой глубины.

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

[Log]
DBMSSQL=info; T:1000

В приведенном выше примере мы указываем серверу записывать информацию о запросах к MS SQL с уровнем info, но только если время выполнения (T) превышает 1000 мс. Такой подход позволяет получить компактный и информативный лог, который легко анализировать вручную или с помощью утилит.

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

Анализ блокировок и взаимоблокировок

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

Для анализа блокировок необходимо включить логирование событий LOCK. Эти события показывают, когда сессия запрашивает блокировку, получает её или ожидает освобождения ресурса. В логе вы увидите идентификаторы сессий, которые участвуют в конфликте, и имена объектов метаданных, которые они пытаются изменить.

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

Тип события	Описание	Уровень важности
LOCK	Запрос или освобождение блокировки объекта	Средний
DEADLOCK	Фиксация факта взаимоблокировки сессий	Критический
LOCK_WAIT	Сессия ожидает освобождения ресурса	Высокий
EXCLUSIVE_LOCK	Установка монопольной блокировки	Высокий

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

Что такое монопольный режим?

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

Диагностика клиент-серверного взаимодействия

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

События уровня CALL и EXCP (исключения) позволяют отследить вызовы методов между клиентом и сервером. Если вы видите, что простой вызов метода занимает непозволительно много времени, возможно, проблема в канале связи, перегруженности сети или в объеме передаваемых данных. Например, передача огромной таблицы значений в одном вызове может «повесить» соединение.

Также стоит обратить внимание на события garbage collection (GC). Сборка мусора в виртуальной машине 1С может вызывать кратковременные, но ощутимые паузы в работе всех потоков процесса. В логе это выглядит как длительная пауза между событиями без явной причины. Если такие паузы частые и длительные, возможно, серверу не хватает оперативной памяти.

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

⚠️ Внимание: Интерфейсы и методы настройки могут отличаться в зависимости от версии платформы 1С:Предприятие (8.3.10, 8.3.20 и новее). Всегда сверяйтесь с официальной документацией для вашей конкретной версии релиза перед редактированием системных файлов.

Использование утилит для обработки логов

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

Самая известная утилита — 1CLogParser (или аналоги от сообщества, такие как OneScript скрипты для анализа). Эти инструменты позволяют загружать лог-файл и фильтровать события по различным критериям: длительность, тип события, имя пользователя. Они могут группировать похожие запросы и показывать статистику по самым «тяжелым» операциям.

С помощью парсеров можно построить график нагрузки на сервер во времени. Это помогает выявить периоды пиковой активности и соотнести их с жалобами пользователей. Например, вы можете увидеть, что каждый день в 10:00 утра система нагружается тяжелыми отчетами, которые запускаются по расписанию.

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

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

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

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

В случаях, когда программная оптимизация невозможна или недостаточна, приходится масштабировать оборудование. Технологический журнал может подсказать, чего именно не хватает: процессорного времени (высокая загрузка CPU при выполнении запросов), дисковой подсистемы (долгое ожидание ввода-вывода) или оперативной памяти (частая сборка мусора).

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

Можно ли включить технологический журнал для одной конкретной базы?

Да, это возможно. В файле ragent.ini можно указать параметр LogDir с путем к конкретной базе или использовать фильтрацию по имени базы в правилах логирования. Это позволяет не засорять логи других информационных баз на том же сервере.

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

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

Влияет ли включенный журнал на скорость работы 1С?

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

Как понять, что проблема в СУБД, а не в 1С?

Если в технологическом журнале видно, что сервер 1С отправил запрос и долго ждет ответ от СУБД (события ожидания DBMS), то проблема, скорее всего, на стороне базы данных (блокировки, нехватка ресурсов, плохой план выполнения).

Нужно ли перезагружать сервер 1С для отключения журнала?

Нет, не обязательно. Можно просто закомментировать строки с правилами логирования в файле ragent.ini и выполнить команду перезагрузки кластера без полной остановки службы, либо дождаться автоматического перечитывания конфигурации, если такая функция поддерживается в вашей версии.