Анализ проблем производительности по динамике мониторинга RAS 1C

07.10.20

База данных - HighLoad оптимизация

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

Мы опишем результаты наблюдений и выводы по состоянию производительности системы через мониторинг RAS 1C основанный на наших наблюдениях и мнении/советах коллег по цеху. Наиболее показательны изменения для больших баз по количеству работающих пользователей на одном кластере. Иначе требуется проводить агрегирование показателей таких как очередь какого-нибудь свойства, если на сервере много кластеров или на реальном много виртуальных машин для общей оценки сервера.

Также на поведение параметров контролируемой целевой базы 1С будет оказывать влияние версия платформы, окружение, конфигурация и это также нужно будет учесть при сравнении.  Однако, динамика и характер поведения должны быть похожи. Мы выполняли анализ на версиях 8.3.14, 8.3.15, 8.3.16 и конфигурации ERP 2.4.

 

I) Свойства процессов

Свойство

Синоним

Функция агрегации

Описание

line-number

номер строки

count

Номер строки (по порядку)

memory-size

память КБ

max

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

memory-size

память КБ

sum

-//-

available-perfomance

дост. произв.

min

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

available-perfomance

дост. произв.

sum

-//-

available-perfomance

дост. произв.

avg

-//-

connections

кол-во соединений

sum

Количество соединений рабочего
процесса с пользовательскими
приложениями.

avg-call-time

 

avg

Показывает среднее время обслуживания
рабочим процессом одного клиентского
обращения. Оно складывается из:
значений свойств AvgServerCallTime,
AvgDBCallTime, AvgLockCallTime,
AvgBackCallTime.

avg-call-time

 

max

-//-

 

Параметр состояния процессов avg-call-time

Параметр avg-call-time – позволяет увидеть проблемы загрузки хоста, если один из них находится под нагрузкой

Вот так выглядит график средней нагрузки

В этот момент было запущено тяжелое задание по пересчету регистра. Всем тем, кто-попадал на этот процесс было «плохо».

Если же все процессы показывают рост нагрузки, то скорее всего проблема возникла у менеджера, и он перестал корректно разруливать ситуацию.

Можно поставить оповещение о изменении данной ситуации, нормальное среднее значение должно быть значительно менее 1. При значениях от 1 до 2-3 возможны проблемы. При значениях более 7-10 можно считать, что мы потеряли пациента.

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

Вот так выглядит показатель среднее avg-call-time при проблемах на сервере.

Вот так выглядит нагрузка на процессор в этот момент:

 

Количество процессов

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

 

Вот так меняется количество процессов при аварии:

 

Показатель расхода памяти

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

 

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

Вот так выглядит падение производительности по показателю доступная производительность:


 

II) Свойства соединений

Свойство Синоним Функция агрегации Описание

session-number

сеанс

count ЗначениеЗаполнено

 Номер сеанса

conn-id

 

count ЗначениеЗаполнено

 Содержит номер соединения. 

line-number

номер строки

count

 Номер строки (по порядку)

 

Показатель соединений session-number

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

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

Для хорошо нагруженной системы обычно такой показатель колеблется в районе 30-40 соединений в единицу.

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

Рекомендуемые агрегируемые функции:

  • session-number - функция количество Значение Заполнено (т.е. для всей таблицы данных считаем только те в которых есть значение отличное от пустого). Определяет очередь из соединенных между собой сеансов и rphost. Чем больше тем хуже. При резком росте характеризует проблемы в управлении соединениями менеджером (или агентом). С ростом этого показателя можно менять удовлетворенность работы пользователей с зелененького на красный.
     

 

III) Свойства сеансов

 

Свойство Синоним Функция агрегации Описание

line-number

номер строки

count

Номер строки (по порядку)

duration-current

время вызова (текущее)

max

Содержит интервал времени в
миллисекундах, прошедший с
момента начала обращения,
в случае, если сеанс выполняет
обращение к серверу 1С:Предприятия.
Иначе – 0.

duration-current

время вызова (текущее)

sum

-//-

duration-current

время вызова (текущее)

count ЗначениеЗаполнено

-//-

db-proc-took

захвачено СУБД

max

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

db-proc-took

захвачено СУБД

sum

-//-

db-proc-took

захвачено СУБД

count ЗначениеЗаполнено

-//-

cpu-time-current

процессорное время (текущее)

max

Процессорное время текущее

cpu-time-current

процессорное время (текущее)

avg

-//-

 

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

 

Свойство duration-current

Показатель duration-current (время вызова (текущее)) показывает обслуживание пользователя процессом. Если же количество пользователей со значением этого параметра (отличным от 0 в каждый момент времени) растет, то сервисы 1с не успевают обслуживать, кто-то запустил что-то тяжелое и в итоге может привести к серьезному снижению производительности. Обычно значения, превышающие 60 штук (зависит от конкретной обслуживаемой системы) повод задуматься о том, что начинаются проблемы.

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

Рекомендуем использовать следующие агрегирующие функции:

  • duration-current - функция количество Значение Заполнено (для колонки таблицы количество ячеек в которых есть значение отличное от 0). Определяет очередь пользователей, которые в данный момент обслуживаются rphost. Обычно растет вверх вместе с нагрузкой на процессор и очередью процессора. Если эти три показателя высоки, то характеризует серьезные проблемы в работе пользователей.
  • duration-current - функция maximum, т.е. среди всех значений вычисляем максимальное. Может характеризовать зависшие сеансы, обработку больших объемов данных или корявый код. Всем пользователям на этом хосте (на том который завис) будет плохо.
     

Свойство db-proc-took

Показатель db-proc-took (захвачено СУБД) характеризует обращение процесса к СУБД. Если количество таких обращений растет в единицу времени, то это говорит о том, что СУБД не успевает обслуживать запросы 1С. Такое поведение может возникать во время блокировок – когда один пользователь захватил популярный регистр, а все другие начинают его ждать. Недостаточной производительности самого сервера СУБД. Наличия большого количества неоптимальных запросов. Наличия операций, которые не рекомендуется запускать в момент высокой нагрузки пользователей – удаление помеченных, пересчет регистров и т.п.

Разбор проблем можно выполнять в соответствии с рекомендациями выше. А также возможно проверить настройку и работу сервисных заданий на сервере СУБД – обновление статистики, или другие настройки.

Рекомендуем использовать следующие агрегирующие функции:

  • db-proc-took - функция количество Значение Заполнено (аналогично выше). Определяет очередь пользователей, которые в данный момент работают с базой SQL. Если есть, то в паре с показателем duration-current. 
    Характеризует работу с базой данных. При росте очереди может характеризовать 
    • - блокировку (тут надо смотреть блокировки SQL) – в этом случае терпеть или срубать;
    • - недостаток мощности сервера SQL – увеличивать мощности;
    • - не оптимальность кода – исправлять код;
    • - выполнение операций не допустимых в рабочее время (к примеру, удаление помеченных, закрытие месяца и т.д.) – дать по рукам пользователям или перенастроить задания.
  • db-proc-took - функция maximum. Если большое, то означает выполнение в транзакции большой обработки данных, или на блокировках.

Показатель cpu-time-current

Данный показатель обычно необходимо смотреть с duration-current. Если он значительно большой, то это говорит о том, что пользователь действительно запустил что-то существенно сжигающее мощность сервера и стоит связаться с пользователем, ограничить или удалить соединение.

Совместный анализ и учет свойств duration-current и db-proc-took

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

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

Если же у вас среднее состояние каждый день показывает высокую нагрузку, то скорее всего следует обновить ваши ресурсные мощности.

Количество пользователей

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

 

IV) Настройка обработки ситуации по комбинации показателей

 

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

Таблица настройки для реакции по комбинациям показателей выглядит следующим образом:

время вызова 
(текущее) (max)
очередь время 
вызова(текущее)
захвачено 
СУБД (max)
очередь 
захвачено СУБД
сеанс 
(count ЗначениеЗаполнено)

Решение

Описание решения

high

high

high

high

*

полное падение производительности

все плохо

high

low

high

low

*

только захват СУБД и 1С время вызова

найти пользователя и срубить

high

high

*

*

*

1С работать невозможно

срубаем все зависшие сеансы

*

*

*

*

high

проблемы с rphost

rphost не справляется с обработкой сеансов

*

*

high

high

*

СУБД работать невозможно

срубаем захваты

high

medium

*

*

*

1С начала формироваться очередь

пора принимать действия

medium

high

*

*

*

1С начала формироваться очередь

пора принимать действия

low

high

*

*

*

1С начала формироваться очередь

пора принимать действия

high

low

*

*

*

1С приложение зависло

нужно срубить пользователя

*

*

high

medium

*

СУБД очередь растет

пора принимать действия

medium

low

*

*

*

1С долго висит

на контроль

*

*

high

low

*

захват СУБД дико долго

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

*

*

medium

low

*

захват СУБД

разобраться в причинах

medium

medium

*

*

*

1С долго висит

на контроль

low

medium

*

*

*

1С зависание ушло

идет в сторону улучшения

*

*

low

medium

*

СУБД захват ушел

идет в сторону улучшения

low

low

low

low

low

нормально

все хорошо

*

*

*

*

*

аномалия

неописанное поведение

 

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

Low – от 0 до допустимого значения

Medium – от допустимого значения до критического

High - от критического до конца.

Наши показатели:

Имя свойства

Начальная 
граница

Низкий до
 

Средний до
 

Верхняя 
граница

время вызова (текущее) (max)

0

60,00000

300,00000

бесконечность

очередь время вызова (текущее)

0

20,00000

40,00000

бесконечность

захвачено СУБД (max)

0

60,00000

300,00000

бесконечность

очередь захвачено СУБД

0

20,00000

40,00000

бесконечность

сеанс (count ЗначениеЗаполнено)

0

60,00000

80,00000

бесконечность

 

Далее по этой таблице мы запускаем обработку нечетким контроллером (виртуальный ассистент Лариса) и формируем оповещения на почту или скайп/телеграмм.

 

V) Бонус. Используем автоматический классификатор ошибок технологического журнала.

 

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

Как видите, то мы тут наблюдаем сообщения об авариях служб 1С и если количество сообщений превышает какое-либо нормальное число (иногда достаточно 1-го сообщения), то необходимо начать проверку. На эти события также можно поставить оповещения ответственных лиц.

На предыдущем рисунке видим проблемы с отбором по классу ошибок СУБД. Из результатов анализа перед коллапсом и последующим падением служб 1С проявляются подобного рода ошибки. Видимо происходит превышение какого-то лимита и службы идут в разнос (8.3.15 версия 1С).

Пример рассмотрения ситуации по ошибкам на мониторе приведена ниже – обращаем внимание на резкие всплески/пики:

 

Заключение:

См. также

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    8489    Evg-Lylyk    61    

43

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    4788    spyke    28    

49

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    7107    vasilev2015    20    

42

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024    11623    223    ZAOSTG    76    

114

HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024    5146    glassman    17    

40

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    11952    doom2good    49    

71
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. VKislitsin 1004 07.10.20 11:32 Сейчас в теме
Владимир, очень интересно! Просто супер!
2. AntoShiK86 31 08.10.20 06:41 Сейчас в теме
Задача по определению активного числа пользователей решается данным фреймворком? Можно определить, что не хватает лицензий ?
4. ivanov660 4565 08.10.20 08:53 Сейчас в теме
(2)
1. Вы можете взять функцию максимум от количество активных пользователей. Таким образом сможете определить пиковые значения пользователей на кластере (На рисунках приведен пример). И исходя из этого можно определить разницу запаса оставшихся лицензий.
2. Если воспользуетесь консолью запросов или напишите свой плагин (обработку/отчет), то можете получить агрегирующие данные по всем отслеживаемым кластерам.
3. В планах стоит доработка для отображения данных по используемым лицензиям пользователями и их составу.
12. AntoShiK86 31 08.10.20 14:08 Сейчас в теме
(4)
те определить пиковые значения пользователей на кластере (На рисунках приведен пример). И исходя из этого можно определить разницу запаса оставшихся лицензий.
2. Если воспользуетесь консолью запросов или напишите свой плагин (обработку


Благодарю за ответ, когда обелить надо организацию, или доказать, что пора покупать еще комплект, может пригодится.
3. kraynev-navi 677 08.10.20 08:14 Сейчас в теме
Владимир, спасибо за вашу аналитику! Как всегда очень полезно.
5. protexprotex 139 08.10.20 10:16 Сейчас в теме
Добрый день. Очень интересно. Но у меня вот такая задача стоит - скорость выполнения процедур 1С (на неуправляемых формах) в разрезе минута/час/день и т.д. В 1С есть замер времени, но этого мало. Как - нибудь подступиться к этой задаче не пробовали?
6. ivanov660 4565 08.10.20 10:39 Сейчас в теме
(5) Не вижу проблемы сделать отчетом по замерам.
К примеру, в выборку запроса детальных записей замеров добавляете поля минута, час, день, неделя, месяц (от даты начала замера), а далее в СКД делаете группировки месяц, неделя, день, час, минута, детальные с итогами среднее по расчетным полям длительность.
7. protexprotex 139 08.10.20 11:30 Сейчас в теме
Неее. Это я знаю. Только для этого в каждую процедуру нужно втыкать фиксацию замера. Типа такого:
Процедура МояПроцедура()
НачатьЗамер("МояПроцедура");
Тут исследуемые операторы программы
ЗакончитьЗамер("МояПроцедура")
КонецПроцедуры

и далее уже, например по записям уже строить СКД

Это не интересно. т.к. нужно по всей базе натыкать эти вызовы. А т.к. процедур более 5000 - это тут, мягко говоря долго.

Я про какие - то сторонние компоненты которые могли бы перехватывать начало выполнения процедуры в языке 1С и конец ее выполнения и вести логи - и оттуда я бы уже через внешний источник данных все это взял и в СКД засунул :-)
8. ivanov660 4565 08.10.20 12:13 Сейчас в теме
(7)
1. Такого в 1С нет.
2. Можно только написать обработку, которая распарсит все формы, все функции и навтыкает в расширение процедуры Перед("Процедура") (возможно + После("Процедура")) и нагенерит код начала и завершения замеров.
3. Только вы учтите что накладные замеры будут огромными, если добавлять везде.
9. protexprotex 139 08.10.20 12:22 Сейчас в теме
(8) Это я знаю что нет такого в 1С. У меня стоит вопрос оптимизации не работы 1С с базой данных, а оптимизация языковых конструкций. Узкое место в 1С это работа с базой данных, но мало кто (да и вменяемых инструментов не нахожу) занимается оптимизацией языковых конструкций. Т.к. 1С я использую для обработки изображений + моя dll. И вот как раз стоит вопрос оптимизация языковых конструкций. Вот.
10. ivanov660 4565 08.10.20 12:29 Сейчас в теме
(9) Попробуйте спросить у автора снегопата, возможно он что-то подскажет.
11. protexprotex 139 08.10.20 12:45 Сейчас в теме
13. EugeneSemyonov 22 21.07.21 13:30 Сейчас в теме
(8) Оптимизацией языковых конструкций следует заниматься когда время выполнения операций превышает целевое.
Для определения длительности операций можно использовать сбор событий ТЖ CALL (на сервере), VRSREQUEST, VRSRESPONSE (или даже все на клиенте) с отбором по длительности. Таким образом вы получите контекст (имя и модуль длительно работавшей процедуры). Часто этого достаточно чтобы понять что именно работает медленно.
Если недостаточно, то можно запускать нужную операцию на тестовом стенде с режимом отладки с замером производительности - так можно поймать короткие, но выполняющиеся многократно операции которые могут приводить к замедлению (типа запросов в цикле).
По документации ТЖ тоже может замедлять работу, но скорее всего это будет оптимальнее чем писать обработчик замера для каждой процедуры.
Кроме того в типовых ещё встроена подсистема Замеры производительности, которая позволяет включать и анализировать нужные замеры в режиме предприятия.
Если вы разрабатываете тиражное решение и хотите вылизать весь код (не важно как быстро он работает), то для его анализа также можно использовать конфигурацию АПК, либо SonarQube.
14. fatman78 20 25.07.23 10:36 Сейчас в теме
Подскажите как побороть ошибку с некорректным отображением кириллицы, если RAS и RAC находятся на разных компьютерах, оба под управлением Windows? Пробовал разные варианты из списка кодировок - эффекта нет...
Прикрепленные файлы:
15. ivanov660 4565 25.07.23 12:29 Сейчас в теме
(14)
Коллега писал (jilitsky.denis@gmail.com), что можно попробовать внести вот такие изменения в обработку. Тогда кодировка должна сохраняться.

Процедура СоздатьCMD(Знач ИмяФайла, Знач Команда)
    
    ЗаписатьФайлВформате_UTF8_без_BOM("cmd.exe /c chcp 866 & " + Команда, ИмяФайла);
    
КонецПроцедуры
16. VenSaitto 16.11.23 10:15 Сейчас в теме
(15)
Кодировка действительно встает корректно, но отваливается отображение графиков истории.
Повторная настройка замеров с нуля помогла не для всех серверов\кластеров 1С.
Возможно есть какое-то другое решение?
17. ivanov660 4565 16.11.23 11:19 Сейчас в теме
(16) Я услышал что есть проблема, но не понял где она происходит и почему. Зарегистрируйте сообщение на портале проекта и опишите подробнее ситуацию для воспроизведения https://github.com/Polyplastic/1c-parsing-tech-log/issues.
Оставьте свое сообщение