Содержание:
1. Диагностика медленных SQL-запросов
2. Диагностика транзакционных блокировок
Технологический журнал — это, без преувеличения, главный диагностический инструмент в арсенале 1С-специалиста. Давайте разберем его применение в деталях.
Когда пользователи жалуются на «тормоза» или «зависания» в 1С, первым подозреваемым часто становится база данных. Однако без объективных данных любые попытки оптимизации превращаются в гадание. Именно для получения таких данных и существует Технологический журнал (ТЖ) — мощнейший механизм платформы 1С: Предприятие, который можно сравнить с бортовым самописцем («черным ящиком»), фиксирующим все ключевые события, происходящие между сервером 1С и СУБД.
Грамотное использование ТЖ позволяет перейти от размытых жалоб к точному диагнозу, находя корень проблемы на уровне конкретного SQL-запроса или транзакционной блокировки.
ТЖ — это набор текстовых лог-файлов, в которые сервер 1С: Предприятие записывает информацию о происходящих событиях в соответствии с настройками. Гибкость его настройки позволяет отслеживать десятки различных событий, но для диагностики проблем с базой данных ключевыми являются всего два: DBMSSQL (или DBPOSTGRS для PostgreSQL) и LOCK.
Диагностика медленных SQL-запросов
Это самая частая задача. Пользователь сообщает, что отчет «Анализ продаж» формируется пять минут, хотя раньше на это уходили секунды.
Шаг 1: Настройка и сбор логов
Для начала нужно включить ТЖ. Для этого в каталоге conf сервера 1С (например, C:\Program Files\1cv8\srvinfo\conf) создается файл logcfg.xml со следующим содержимым:
<config xmlns=”http://v8.1c.ru/v8/tech-log”>
<log location=”C:\1C_Logs” history=”24″>
<event>
<eq property=”Event” value=”DBMSQL” />
</event>
<property name=”Sql”/>
<property name=”Context”/>
</log>
</config>
- location: Путь, куда будут сохраняться логи. Убедитесь, что у службы сервера 1С есть права на запись в эту папку.
- history: Сколько часов хранить логи.
- event: Указываем, что нас интересует событие DBMSSQL (для MS SQL).
- property: Просим дополнительно выводить полный текст SQL-запроса (Sql) и контекст его вызова в коде 1С (Context).
После сохранения файла необходимо перезапустить службу Агента сервера 1С: Предприятие.
Шаг 2: Воспроизведение проблемы
Просим пользователя (или делаем это сами на тестовой копии) запустить тот самый медленный отчет. В папке C:\1C_Logs начнут появляться лог-файлы.
Шаг 3: Анализ логов
Открываем лог-файл и ищем записи. Каждая запись выглядит примерно так:
20:15.123456-15280,DBMSQL,1,process=rphost,p:processName=Trade,d=…
Duration=5123456, …
Sql=SELECT T1.Field1, T2.Field2 FROM Table1 AS T1 INNER JOIN Table2 AS T2 …
Context=
Модуль.Отчет.АнализПродаж.Форма.Отчета.Модуль : 125 : Запрос.Выполнить()
Модуль.Отчет.АнализПродаж.Форма.Отчета.Модуль : 150 : СформироватьОтчет()
На что мы смотрим:
- Duration: Длительность выполнения SQL-запроса в микросекундах. Наша цель — найти записи с аномально большими значениями. 5123456 мкс — это ~5.1 секунды. Это наш «виновник».
- Sql: Полный текст SQL-запроса, который был отправлен в СУБД. Именно этот текст можно скопировать в SQL Server Management Studio для дальнейшего анализа плана выполнения и поиска причин медленной работы (например, отсутствия индекса).
- Context: Самая ценная часть. Это стек вызовов, который показывает, какая именно строка кода в конфигурации 1С инициировала этот медленный запрос. В нашем примере мы видим, что запрос был выполнен в 125-й строке модуля формы отчета «Анализ продаж».
Теперь у нас есть полный диагноз: мы знаем, какой SQL-запрос тормозит и какой код 1С его порождает.
Диагностика транзакционных блокировок
Другая частая проблема: система «зависает», пользователи не могут провести документы. Скорее всего, один процесс захватил ресурсы и мешает другим.
Шаг 1: Настройка технологического журнала
Модифицируем logcfg.xml, добавив отслеживание события LOCK:
<config xmlns=”http://v8.1c.ru/ v8/tech-log”>
<log location=”C:\1C_Logs” history=”24″>
<event>
<eq property=”Name” value=”LOCK” />
</event>
</log>
</config>
Шаг 2: Анализ логов
Во время «зависания» в логах появятся записи о конфликтах блокировок. Они могут выглядеть так:
20:20.123456-1500,LOCK,1,process=rphost,p:processName=Trade, …
WaitConnections=1501,
Regions=dbo.AccumRg1234,
Context=
Сеанс: 15, Пользователь: Бухгалтер, Приложение: Тонкий клиент
Модуль.Документ.ПоступлениеТоваров.МодульОбъекта : 250 : Движения.Записать()
Что это нам говорит:
- WaitConnections: Номер соединения, которое ожидает освобождения ресурса.
- Regions: Таблица или диапазон данных, на которых произошел конфликт.
- Context: Контекст процесса, который удерживает блокировку. В нашем примере мы видим, что бухгалтер проводит документ «Поступление товаров», и именно этот процесс мешает другим.
Проанализировав контекст обоих процессов (удерживающего и ожидающего), мы можем понять причину. Часто это длительная транзакция, внутри которой происходит сложный расчет или, что еще хуже, ожидание ответа от пользователя.
Вывод:
Технологический журнал — незаменимый инструмент, который переводит диагностику проблем с базой данных из области догадок в плоскость инженерного анализа. Он предоставляет объективные данные о том, что на самом деле происходит «под капотом» системы. Научившись читать и интерпретировать логи ТЖ, 1С-специалист получает возможность быстро и точно находить «бутылочные горлышки» производительности, будь то неоптимальный запрос или конфликт блокировок, и точечно устранять их, возвращая системе скорость и стабильность.
Специалист компании ООО “Кодерлайн”,
Радченко Степан
Добавить комментарий