Счетчик потребления ресурсов 1с настройка

Обновлено: 08.07.2024

Честно говоря, сейчас все вопросы использования 1С, как администрирования, там и обычной работы отлично освещены в ИТС, с картинками и примерами.
Иногда даже полнее чем в сторонних публикациях, чего стоят например чек-листы по настройке серверов в продакте.
Поэтому эту статью можно рассматривать как иллюстрацию (дополнение к) официальной документации по механизму управления потреблением ресурсов платформы 1С:Предприятие 8.3.13 и следующих разумеется.
А так же возможные сценарии использования, если в комментариях появятся дельные варианты, я думаю это всем пойдет на пользу.
Многие побоялись ее (платформу) устанавливать, из суеверных соображений или из соображений практичности. Для них будет интересно.

Решение:

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

Тестовый контур и порядок работы:

Как работает механизм вкратце:

В консоли управления кластером добавлены два новых раздела: счетчики потребления ресурсов и ограничения потребления ресурсов.
Информация, накопленная счетчиками, может отображаться в консоли кластера (каких либо программных способов доступа к ней или созданию объектов из встроенного языка, пока не обнаружил, будет один лайфхак в конце статьи), а может еще и использоваться механизмом ограничения потребления ресурсов.
Замеры производятся либо в плавающем интервале заданной длительности (когда счетчик настроен на анализ показателей за интервал времени, то срабатывание ограничений будет действовать пока показатели счетчика не станут меньше контрольных), либо за серверный вызов.
Собираемая информация условно поделена на три вида:

Время (Серверные вызовы, Процессорное время, Время вызовов СУБД, Время вызовов сервисов)
Объем данных в байтах (Объем оперативной памяти, занятой сеансом, Объем данных, прочитанных с диска, Объем данных, записанных на диск, Объем данных, которые были переданы и получены при работе с СУБД)
Количественные показатели (Количество серверных вызовов, Количество активных сеансов, Общее количество сеансов за интервал измерения)

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

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

Ограничение потребления ресурсов опирается на данные одного конкретного счетчика и при превышении любого из контролируемых показателей может выполнить четыре действия:

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

На этом теория заканчивается, все более подробно описано в ИТС.

Стоят верблюд-сын и верблюд-отец.
Сын: Папа, а зачем нам на спине нужен горб?
Отец: В горбу, сынок мы накапливаем воду и когда идем по пустыне нас не мучает жажда.
С: Папа, а зачем нам такие копыта?
О: Это чтобы ходить по песку и ноги не проваливались.
С: А зачем нам такие большие и жесткие губы?
О: Это чтобы в пустыне можно было есть колючки
С: Тогда папа объясни мне, на хрена нам весь этот тюнинг в Саратовском зоопарке.
© анекдот.ру

Откуда мотивация понятно - для работы во фреше, а также на крупных внедрениях необходимо как то упорядочивать работу пользователей.
В MS SQL есть похожий механизм, честно говоря думал, что 1С к нему подцепится. Но он насколько я помню в редакции Enterprise.
Опять же если свести воедино информацию всех счетчиков, можно сделать подобие биллинга и выставлять счет по реально потребленным ресурсам.
По большому счету, если проследить все последние изменения платформы, все они нацелены на поддержку облачных и немаленьких решений.
И последние редакции содержат столько наворотов, что использовать их все в одной обычной группе компаний просто не реально.
Если так пойдет и дальше, то нужна будет еще одна версия платформы между базовой и обычной - для среднего бизнеса.

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

Первый тест: ограничение количества активных сеансов для пользователя (для затравки):

Второй тест: понижение приоритета потока для пользователя информационной базы:

В ИТС это понятие не расшифровывается.
"понизить приоритет потока, который исполняет текущий серверный вызов" на сколько (во сколько) раз непонятно.
На глаз замедление заметно, как измерить это замедление для разных пользователей работающих в одной базе, чтобы получить количественные результаты я не придумал.
Этот вариант использования наверное самый востребованный.
Если сделаете такой для главного бухгалтера в дни отчетности - он вас прославит в веках.
А сделать легко: фильтр по имени пользователя, тип отбора - все кроме выбранных, вид ограничения - понижение приоритета потока.
Вжух, и все менеджеры работают медленно, а бухгалтерия быстро.

Третий тест: понижение приоритета потока для информационной базы целиком:

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

Для этого были запущены две одинаковые базы 1С, одна с применением ограничения "Понижение приоритета потока"

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

И на этих базах запущены тесты производительности из прошлых статей.
Их результаты в виде таблицы:

Тест/Конфигурация ВМ	1C
	gilev.ru	APDEX	fragster.ru (Результат на поток)
	Временные таблицы	Справочники	Регистры сведений	Регистры накопления	Регистры бухгалтерии
Без ограничения	16,72	0,989	2 016,16	290,21	290,21	237,69	238,52
С ограничением процессорного времени	1,67	0,806	1 361,26	185,09	138,72	129,22	130,85

Единственное отличие - запускал тесты в обратном порядке.
Сначала APDEX с количеством 10 пользователей в базе.

Тренер утешает проигравшего боксера:
- А все-таки в третьем раунде ты своего противника здорово напугал.
- Чем это?
- Ему показалось, что он тебя убил.
© анекдот.ру

Продавцам зонтов надо молиться на дождливое лето.
Продавцам сандалий надо молиться на сухое лето.
Продавцам пива надо молиться на жаркое лето.
А продавцам водки некогда молиться, им надо продавать!
© анекдот.р

Тест четвертый: нереализованный:

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

Больше вариантов у меня не набралось. Это не значит, что их нет вообще. Может как раз для кого то критично количество байт переданных СУБД или количество серверных вызовов и они будут срубать пользователей за это.
Собственно для это и существуют комментарии к публикации, чтобы все желающие могли высказаться по существу.
За лучший вариант - небольшое вознаграждение.

Как все это работает:

Все настройки созданных счетчиков и ограничений хранятся в файле реестра кластера 1CV8Clst.lst (1CV8Clsto.lst) расположенном в каталоге данных рабочего сервера, отмеченного как центральный.

Все результаты счетчиков записываются в текстовый файл rescntsrv.lst находящемся там же.
Формат совпадает.

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

Итог:

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

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

Желающие что-то подтвердить, опровергнуть или еще раз уточнить для себя, не вижу что вас может остановить.

Ссылки на использованные публикации.

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

Если вы не представляете: что такое 1С Предприятие, файл и зачем вам нужна эта кухня.

Все файлы из интернет считаете зараженными вирусом.

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

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

Закройте эту страницу не продолжая чтения дальше.

Для адекватных людей:

Если у вас есть конкретные замечания или предложения по улучшению - пишите.

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Реализовано в версии 8.3.13.1513.

Механизм управления потреблением ресурсов решает три основные задачи:

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

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

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

Счетчики и ограничения

Для управления механизмом мы добавили в настройки кластера два новых объекта:

Счетчик потребления ресурсов,
Ограничение потребления ресурсов.

Для управления этим механизмом вы можете использовать не только Windows утилиту администрирования кластеров (на рисунке), но и сервер администрирования (ras) c одним из кроссплатформенных инструментов: утилитой командной строки (rac) или java-интерфейсом.

Счетчик потребления ресурсов

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

Эти новые показатели позволяют вам замерять нагрузку на процессор и отслеживать общее количество запущенных сеансов.

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

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

Ограничение потребления ресурсов

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

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

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

Прерывание текущего серверного вызова

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

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

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

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

О счетчиках и ограничениях

Для администрирования нового механизма в настройки кластера были добавлены два объекта:

ограничение потребления ресурсов;
счетчик потребления ресурсов.

Производить настройку этих объектов можно с помощью утилиты Windows для администрирования кластеров, а также используя сервер для администрирования (ras) с одним из инструментов: java-интерфейсом либо утилитой командной строки (rac).

Считаем потребление ресурсов

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

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

Устанавливаем ограничения

Прерывание серверного вызова

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

Лучше бы паузу нативно реализовали. За 15 лет то можно уж было.

(1) Через обработчик ожидания, можно попробывать сделать или через бесконечный цикл с прерыванием по времени, это если нативно :3

У меня в публикациях есть внешняя компонента для винды, эмулирующая нажатия клавиш и паузу с помощью WinApi

(2) Да в коипонентах - оно не только у Вас есть. но вот именно средствами платформы - нету. (1) +100500
(2) вариантов несколько, непонятно почему до сих пор в движок не запилят (1)паузы - зло, есть асинхронное исполнение - этого более чем достаточно.
Если вы захотели паузу - это говнокод.
Единственный вариант использования паузы - это ограничение на кол-во запросов в секунду(минуту, час, день и т.д) к какому то сервису, и то спокойно решается корректным запуском фоновых задач. (11)
Сфигали корректно это? А если надо выполнять действия на клиенте, а не на сервере?
Помимо того, возникает излишняя нагрузка по организации этих самых фоновых задач.

(11)фоновые задачи требуют ресурсов, а sleep() - это тот самый простой, во время которого платформа запустит (или не запустит если не нужно) фз

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

Расскажи это разработчикам платформы и всем, кто использует вот такую строчку в коде:

(29) ну не могут все сразу переписать на асинхронные вызовы.
будем ждать ОжидатьЗавершения(<ФоновыеЗадания>, <Таймаут>, <ОписаниеОповещенияОЗавершении> )
(25) ПодключитьОбработчикОжидания(<ИмяПроцедуры>, <Интервал>, <Однократно>) - чем плох? ПодключитьОбработчикОжидания (<ИмяПроцедуры>, <Интервал>, <Однократно>) - чем плох?
тем что не всегда в типовой все написано асинхронно, и нужно переписывать. Согласен, глобально это решение, но на практике - оверинжиниринг (29) при чем тут-то пауза - ФоновыеЗадания.ОжидатьЗавершения используется, например когда перед следующим этапом расчета дождаться пока выполнятся все N параллельных фоновых заданий предыдущего этапа расчета.

Да, знаю. Активно использую. А теперь представим, что у нас есть 3 неравных порции данных, но одновременно мы может запустить только 2. Разница в размерах порций примерно такая 100%-200%-300%. Т.е. Запустив 2 задания, мы будем ждать пока отработает самое долгое из них. Это если использовать ФоновыеЗадания.ОжидатьЗавершения. Вместо этого можно вручную проверять завершение заданий и, когда завершится более быстрое из двух, запустить третье.
Понятно, что можно вместо *Пауза ( 1 ) можно использовать ФоновыеЗадания.ОжидатьЗавершения (массивЗаданий, 1 ), но ему нужен массив, плюс работает этот метод только через попытку. Можно, но нативная пауза была бы приятнее.

Контроль потребдяемых ресурсов сервера 1с является одной из основных задач администратора и позволяет выявлять наиболее ресурсно затратные объекты. Эту задачу выполняет предлагаемая обработка (управляемые формы). Обработка работает для клиент-серверных баз данных через com-соединение установленное на сервере 1с. Тестировалась на релизе платформы 1С:Предприятие 8.3.14.1630 в режиме совместимости с 1С:Предприятие 8.2 и релизе конфигурации "Расчеты с населением за газ + ВДГО (1.2.1.2), базы данных на MS SQL сервере . Релиз конфигурации не имеет значения.

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

Выпадающий список "Измерение", позволяет выбрать три типа измерений

1. "База данных" - осуществляется контроль ресурса по всем сеансам выбранных баз данных.

2. "Пользователь"- осуществляется контроль ресурса по пользователям выбранных баз данных.

3. "Приложение" - осуществляется контроль ресурса по всем приложениям выбранных баз данных (Тонкий,толстый клиенты, конфигуратор, веб клиент. ).

В настройке "Время опроса" задается интервал времени между опросами сеансов баз данных кластеоа 1с

Для выявления наиболее ресурсно затратных объектов. Введена настройка "Максимальный ресурс" + "Количество".Эта настройка позволяет отобрать объекты потребляющие максимальное количество выбранного ресурса. Количество таких объектов устанавливается в реквизите "Количество". Таким образом при установленных на рисунке настройках будут выбраны три абонента с максимальными значениями ресурса "Объем данных (5 мин)" по выбранным базам данных. Абоненты отбираются по максимальному значению ресурса в начальный момент процесса мониторинга.

3. Мониторинг.

Запуск мониторинга осуществляется нажатием кнопки "Старт". Кнопка "Пауза" приостанавливает процесс мониторинга. Кнопка "Остановить" останавливает мониторин и сбрасывает все данные . Кнопка "Получить точку на графике" выводит на график одно измерение ресурса.

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

Последняя версия обработки содержит контроль версии платформы, для исключения ошибки выбора ресурса "Процессорное время".

Версия 1.1

Дополнительно содержит 2 ресурса - "Время с последней активности сеанса." и "Время с начала сеанса."

Добавлена новая закладка "Настройки диаграммы", которая позволяет выбрать любой из предлагаемых типов диаграммы.

В закладку "Мониторинг" добавлено два новых реквизита. Реквизит "Тип графика" - показывает тип формируемой диаграммы и "Обновление при каждом опросе". Установка реквизита "Обновление при каждом опросе", позволяет на каждом измерении создавать новую диаграмму. Этот реквизит актуален например для типов диаграммы "Круговая". Без его установки эти диаграммы просто не будут меняться.

Ниже приведены примеры диаграммы "Изометрическая непрерывная", без "Обновления при каждом запросе" и с обновлением при каждом запросе.

Версия 1.2

Добавлены ресурсы - Спящие сеансы, Лицензии, Лицензии по типам.

Для серии ресурса "Лицензии по типам", например, имеющего значение "Клиент, ORGL8 Сет 100" получаем следующую расшифровку - клиентский сетевой ключ, тип ORGL8, на 100 пользователей.

Введен режим работы диаграммы "Фиксированное окно просмотра". Режим устанавливается двумя реквизитами "Использовать фиксированное окно просмотра" и "Количество точек измерения в окне просмотра". При установленных значениях на рисунке ниже, окно просмотра будет содержать 50 последних точек измерения.

Пример работы режима иллюстрируют последние 2 рисунка.