Постановка задачи:
Честно говоря, сейчас все вопросы использования 1С, как администрирования, там и обычной работы отлично освещены в ИТС, с картинками и примерами.
Иногда даже полнее чем в сторонних публикациях, чего стоят например чек-листы по настройке серверов в продакте.
Поэтому эту статью можно рассматривать как иллюстрацию (дополнение к) официальной документации по механизму управления потреблением ресурсов платформы 1С:Предприятие 8.3.13 и следующих разумеется.
А так же возможные сценарии использования, если в комментариях появятся дельные варианты, я думаю это всем пойдет на пользу.
Многие побоялись ее (платформу) устанавливать, из суеверных соображений или из соображений практичности. Для них будет интересно.
Решение:
Как я уже писал ранее, каждое тестирование облачных платформ использовалось еще и для прояснения некоторых вопросов, возникающих у меня.
Не стало исключением и 1С в облачной платформе Microsoft. В Azure все в ажуре? (спасибо Microsoft за просто громадную сумму выделенную на тестовый период)
В нем попробовал на зуб, как работает механизм управления потреблением ресурсов.
Тестовый контур и порядок работы:
Использовалась виртуальная сеть:
Сервер Windows 2008 R2 2 ядра 8 Гб ОЗУ и 50 Гб HDD SSD Premium
Рабочие станции Windows 10 1809 1 ядро, 3.5 Гб ОЗУ 50 Гб HDD SSD Standart
1С:Предприятие 8.3 (8.3.13.1644), сервер и клиентские приложения 32-х разрядные, конфигурация Бухгалтерия предприятия, редакция 3.0 (3.0.66.70)
Тестовые конфигурации 1С с сайтов www.gilev.ru и fragster.ru, а также обработка эмулирующая работу пользователей в 1С Бухгалтерия предприятия.
Тестирование проводилось с рабочих станций.
Как работает механизм вкратце:
В консоли управления кластером добавлены два новых раздела: счетчики потребления ресурсов и ограничения потребления ресурсов.
Информация, накопленная счетчиками, может отображаться в консоли кластера (каких либо программных способов доступа к ней или созданию объектов из встроенного языка, пока не обнаружил, будет один лайфхак в конце статьи), а может еще и использоваться механизмом ограничения потребления ресурсов.
Замеры производятся либо в плавающем интервале заданной длительности (когда счетчик настроен на анализ показателей за интервал времени, то срабатывание ограничений будет действовать пока показатели счетчика не станут меньше контрольных), либо за серверный вызов.
Собираемая информация условно поделена на три вида:
- Время (Серверные вызовы, Процессорное время, Время вызовов СУБД, Время вызовов сервисов)
- Объем данных в байтах (Объем оперативной памяти, занятой сеансом, Объем данных, прочитанных с диска, Объем данных, записанных на диск, Объем данных, которые были переданы и получены при работе с СУБД)
- Количественные показатели (Количество серверных вызовов, Количество активных сеансов, Общее количество сеансов за интервал измерения)
Создаваемый счетчик позволяет собирать любые из этих показателей в любой комбинации.
При этом возможна фильтрация (на равенство или на неравенство) по имени информационной базы, имени пользователя, по значениям разделителей областей данных, по идентификатору приложения, использующего сеанс. Также в различных комбинациях.
Ограничение потребления ресурсов опирается на данные одного конкретного счетчика и при превышении любого из контролируемых показателей может выполнить четыре действия:
- записать событие в технологический журнал и не делать ничего,
- завершить серверный вызов,
- завершить сеанс,
- понизить приоритет потока.
На этом теория заканчивается, все более подробно описано в ИТС.
Стоят верблюд-сын и верблюд-отец.
Сын: Папа, а зачем нам на спине нужен горб?
Отец: В горбу, сынок мы накапливаем воду и когда идем по пустыне нас не мучает жажда.
С: Папа, а зачем нам такие копыта?
О: Это чтобы ходить по песку и ноги не проваливались.
С: А зачем нам такие большие и жесткие губы?
О: Это чтобы в пустыне можно было есть колючки
С: Тогда папа объясни мне, на хрена нам весь этот тюнинг в Саратовском зоопарке?...
© анекдот.ру
Откуда мотивация понятно - для работы во фреше, а также на крупных внедрениях необходимо как то упорядочивать работу пользователей.
В 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 пользователей в базе.
Далее тесты уважаемого fragster.ru
Тренер утешает проигравшего боксера:
- А все-таки в третьем раунде ты своего противника здорово напугал.
- Чем это?
- Ему показалось, что он тебя убил.
© анекдот.ру
И на закуску тест с gilev.ru. С ним вообще вышел полный оверкиль. Я уже думал, что все зависло.
Пробовал несколько раз. Чистил кеши, перезагружал базу. Похоже новый механизм от 1С прибивает его начисто.
Позволю себе высказать предположение, что понижение приоритета нелинейное, чем активнее "нарушитель" использует процессор сервера, тем активнее 1С его притормаживает.
Поэтому APDEX пострадал не сильно, более агрессивный тест дал большее замедление, а тест Гилева, который упирается в сервер напрямую, замедлился совсем.
К тому же первые два теста "размазывают" нагрузку по нескольким сессиям, а тест Гилева идет под одним.
Впрочем возможно дело и в реализации самих тестов.
Продавцам зонтов надо молиться на дождливое лето.
Продавцам сандалий надо молиться на сухое лето.
Продавцам пива надо молиться на жаркое лето.
А продавцам водки некогда молиться, им надо продавать!
© анекдот.р
Тест четвертый: нереализованный:
Наверное при вдумчивом подходе, можно снять базовую линию нагрузки сервера по процессорному времени и настроить ограничение для выходящих за нее.
С другой стороны, у всех систем есть выраженная в той или иной степени сезонность (для бухгалтерии это дни сдачи отчетности, для кадровиков - выплаты заработной платы, оперативный учет тоже привязан обычно к времени года).
Больше вариантов у меня не набралось. Это не значит, что их нет вообще. Может как раз для кого то критично количество байт переданных СУБД или количество серверных вызовов и они будут срубать пользователей за это.
Собственно для это и существуют комментарии к публикации, чтобы все желающие могли высказаться по существу.
За лучший вариант - небольшое вознаграждение.
Как все это работает:
Все настройки созданных счетчиков и ограничений хранятся в файле реестра кластера 1CV8Clst.lst (1CV8Clsto.lst) расположенном в каталоге данных рабочего сервера, отмеченного как центральный.
Все результаты счетчиков записываются в текстовый файл rescntsrv.lst находящемся там же.
Формат совпадает.
Таким образом можно разбирать замеры счетчиков и передавать их в тот же Zabbix не настраивая технологический журнал.
Преимущество перед технологическим журналом в том что файл не разрастается, а старые события вытесняются новыми в пределах плавающего окна заданного в процессе настройки счетчика(ов).
Безусловно при определенной сноровке можно и ТЖ привести к подобному виду.
Итог:
Достаточно интересный механизм уже на сегодняшний день и наверняка он будет дорабатываться и обрастать новыми возможностями.
А они ограничены только вашей фантазией.
На сегодняшний день не хватает документации, из-за этого сложно выстроить варианты применения.
Очень хорошо, что в платформу добавляются новые возможности, облегчающие жизнь DBA.
Жалко, что скоро эти возможности будут доступны только обладателям лицензии КОРП.
Желающие что-то подтвердить, опровергнуть или еще раз уточнить для себя, не вижу что вас может остановить.
Ссылки на использованные публикации.
- 1С:Предприятие 8.3.13. Документация
- Тест производительности 1С fragster.ru
- Тест производительности 1С gilev.ru
- 1С в облачной платформе Microsoft. В Azure все в ажуре?
Не верю, что мне приходится писать для пользователей этого сайта, но как оказалось нужно.
Если вы не представляете: что такое 1С Предприятие, файл и зачем вам нужна эта кухня.
Все файлы из интернет считаете зараженными вирусом.
Если физиологические, моральные, религиозные или другие причины не позволяют вам заполнять справочники, документы, настраивать отчеты 1С и запускать обработки.
А платить вы за это не будете так как программист с десятилетним стажем.
Закройте эту страницу не продолжая чтения дальше.
Для адекватных людей:
Если у вас есть конкретные замечания или предложения по улучшению - пишите.
