ЦУП. Сбор данных показателей

Чтобы проанализировать данные производительности, нужно эти данные сначала собрать. Для этого в ЦУП предназначен сценарий «Мониторинг». Всего в сценарии доступно 22 показателя, разделенных на 5 групп. Для сбора данных по этим показателям ЦУП использует 3 источника данных: данные агента кластера 1С, счетчики операционной системы, технологический журнал.

Статья актуальна для ЦУП версии 2.0.19.02.

Чтобы проанализировать данные производительности, нужно эти данные сначала собрать. Для этого в ЦУП предназначен сценарий "Мониторинг". Всего в сценарии доступно 22 показателя, разделенных на 5 групп. Для сбора данных по этим показателям ЦУП использует 3 источника данных: данные агента кластера 1С, счетчики операционной системы, технологический журнал.

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

Каждая группа показателей использует определенные источники данных, поэтому рассмотрим их по отдельности.

Группа показателей "Запросы"

"Суммарное время выполнения запросов"
"Максимальное время выполнения запросов"
"Среднее время выполнения запросов"
"Количество выполняемых запросов"

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

Количество выполняемых запросов вычисляется как количество соединений, выполняющих запросы к СУБД в данный момент. Иными словами, количество соединений, у которых в данный момент свойство durationCurrentDBMS > 0.

Группа показателей "Ожидания на блокировках". Блокировки СУБД

"Суммарное время ожидания на блокировках СУБД"
"Максимальное время ожидания на блокировках СУБД"
"Среднее время ожидания на блокировках СУБД"
"Количество текущих ожиданий на блокировках СУБД"
"Количество таймаутов"

Первые 4 показателя работают аналогично показателям из группы "Запросы", только вместо свойства durationCurrentDBMS у соединений анализируется BlockedByDBMS (Идентификатор cоединения, блокирующего работу данного соединения (в СУБД)). Т.к. в этом свойстве храниться номер соединения, то время ожидания на блокировках вычисляется как ТекущееВремя — ВремяНачалаБлокировки. Время начала блокировки определяется как время начала первого такта, в котором возникло ожидание.

Количество таймаутов — здесь уже используется счетчик операционной системы "SQL Server: LocksLock Timeouts (timeout > 0)/sec". Если открыть Performance Monitor и добавить этот счетчик, то показания совпадут с теми, что отобразит ЦУП.

Группа показателей "Ожидания на блокировках". Блокировки 1С

"Суммарное время ожидания на блокировках 1С"
"Максимальное время ожидания на блокировках 1С"
"Среднее время ожидания на блокировках 1С"
"Количество текущих ожиданий на блокировках 1С"

Анализируется свойство blockedByLM (идентификатор соединения, блокирующего работу данного соединения) описания соединений агента кластера. В остальном показатели работают также, как и показатели ожидания на блокировках СУБД.

Группа показателей "Взаимоблокировки"

"Количество взаимоблокировок MS SQL Server"

Обрабатывается счетчик операционной системы "SQL Server: LocksNumber of Deadlocks/sec". Хоть в названии и стоит "/sec", но на самом деле счетчик кумулятивный.

Группа показателей "Анализ"

"Анализ запросов"
"Анализ ожиданий на блокировках"
"Анализ взаимоблокировок MS SQL Server"

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

"Анализ запросов". Включается технологический журнал с двумя событиями: DBMSSQL и SDBL. Для каждого события устанавливается отбор по длительности (свойство duration). Значение длительности указывается в параметрах показателя.

"Анализ ожиданий на блокировках". Используется сразу два лога ТЖ. Один с событиями DBMSSQL и SDBL для ожиданий на блокировках СУБД. Второй с TLOCK и SDBL с отбором по событию BeginTransaction для анализа ожиданий на блокировках 1С (включается только в том случае, если режим управления блокировками управляемый).

"Анализ взаимоблокировок MS SQL Server". Включается ТЖ по событиям DBMSSQL и SDBL. Также включается трассировка MSSQL по событию Deadlock graph.

Если у показателей "Анализ ожиданий на блокировках" и "Анализ взаимоблокировок MS SQL Server" стоит параметр "Получать планы запросов", то в файл настроек ТЖ добавится свойство planSQLText.