Рекомендуемые настройки сервера 1С предприятия при массовом обмене

#1

На предприятии несколько баз (10 штук) лежат на одном сервере предприятия и массово обмениваются данными между собой через RabbitMQ.
При этом:

  1. каждая база получает данные из нескольких очередей (2-4)
  2. есть желание ускорить обмен, использую параллельное чтение из каждой очереди в нескольких фоновых заданиях (бизнес-процесс это позволяет)
  3. есть необходимость получать данные по обменам более-менее оперативно

Проблема заключается в том, что

  1. подобная организация процесса приводит к появлению большого количества одновременно-работающих фоновых заданий 102<количество для параллельного чтения>
  2. каждое фоновое задание пытается полностью утилизировать одно ядро процессора на сервере
  3. в результате процессор периодически бывает занят на 100% и в это время интерактивно в базах работать невозможно

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

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

#2

А с какой частотой запускаются фоновые задания, которые читают данные из очередей?

Не совсем понятно, данные из очередей приходят с задержкой равной сетевой задержке, то есть практически без задержки.

#3

А с какой частотой запускаются фоновые задания

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

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

А хотелось бы, сделать так, чтобы на задачи связанные с обменом тратилось не больше 50% процессора на сервере, т.е. ограничить сверху потребление ресурсов, связанно с обменом (пусть в ущерб скорости обработки получаемых данных), но чтобы это делалось в автоматическом режиме.

#4

Менеджер заданий НЕ предлагать ?

#5

А что имеется в виду по менеджером заданий? Платформенный, который в файловом варианте используется, или обработка Консоль заданий?

#6

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

#7

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

#8

А данные что ли идут непрерывным потоком и во все базы? Странно просто что загрузка цпу на сервере 1с 100%.

#9

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

  1. обмен настроен так, что номенклатура расходиться во все базы
  2. в середине рабочего дня менеджер обработкой в одной из баз загружает номенклатуру поставщика из прайс листа (несколько тысяч/десятков тысяч позиций), и она уезжает в оставшихся 9 баз
  3. т.к. это происходит одновременно (и базы на одном сервере), то этим 9 базам для того чтобы загрузить эту номенклатуру нужно 30 минут
  4. в течении этих 30 минут пользователям в базе работать невозможно, т.к. получение данных из кролика утилизирует 100% процессора

Т.е. понятно, что тут можно придумывать разные специфичиеские и локальные способы обхода именно этой проблемы. Но хотелось бы общего решения “как не дать обменам съедать более 50% ресурсов сервера”

#10

Валер. Прости - но у нас просто разных глоссарий. В подсистеме НЕТ понятия “обмен”, а тем более массовый. Просто вы заложники своей архитектуры адаптера, который пилили сами.

Есть понятия

Подсистема Интеграции

  • событие
  • сообщение
  • канал отправки
  • канал получения
  • канал асинхронного вызова и обработки ответа

Подсистеме менеджера заданий

  • исполнитель
  • менеджер исполнителей
  • очередь заданий

Я даже не знаю как тебе ответить по нормальному. Кроме как вы делаете что-то странное и мне непонятное. Ты уткнулся в проблему - но проблема не в массовости обмена, а то как вы реализовали исполнителей и события.

#11

Ок, пример который я привел выше не имеет никакого отношения к адаптеру (там ни одного термина связанного с адаптером нет).
Приведу его еще раз:

Если для получения сообщений мы используем “Подсистему интеграции”, после отправки номенклатуры из одной базы в оставшихся 9 в “канал получения” каждой из 9 баз одновременно поступит несколько тысяч сообщений и регл. задание “Получение сообщений из очередей” в каждой базе начнет их обработку.

Т.к. исходное событие отправляется во все базы, и все базы постоянно держат “канал получения” открытым, то и обработку они начинают одновременно.
В результате в один момент времени регл. задания получения сообщений в каждой базе начинает съедать полностью ресурсы одного ядра сервера.
В результате загрузка сервера 100% и в это время пользователи интерактивно работать не могут.

Т.е. я не понимаю причем тут Адаптер (он работает на более высоком уровне), суть проблемы в том, что:

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

Вопрос про это

#12

Подсистема “Менеджер заданий имени Е.Павлюка” или “доклад Map&reduce имени Серебряной Пули, презентованный Ильгизом Туальбаевым” или подсистема “обработки имени"Артема Кузнецова” - есть еще доклад на последнем Инфостарте в секции инструментарий про многопоточную обработку.

Я рекомендую для начала взять подсистему Жени Павлюка и использовать ее как базу (не забудьте вставить лицензию с указанием копирайтов".

#13

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

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

P.s. У вас была проблема - в один поток долго шёл обмен. Вы сделали сто потоков, теперь обмен идёт быстро, но тормозит все остальное. Ищите баланс производительности и скорости.

4 Симпатий
#14

В плане различных подсистем, которые могут ограничить количество одновременно работающих регл заданий, ещё могу порекомендовать бспшную подсистему “Очередь заданий”

#15

@lustin @nixel2007 Большое спасибо за информацию. Посмотрел на указанные вами менеджеры “Менеджер заданий имени Е.Павлюка” и “Очередь заданий”. Принцип работы у них примерно один и тот - же:

  1. Ставим все задания в очередь
  2. Задаем общие параметры выполнения заданий из очереди: ограничение на одновременное количество выполняемых задний, и/или общее расписание
  3. Управляем общей очередью, а не каждым заданием по отдельности

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

  • либо оно висит и ждет сообщений
  • либо обрабатывает сообщения (но все равно при этом висит)

Т.е. если “тупо” применить указанные вами менеджеры заданий к задачам обмена, то просто запустятся первые попавшиеся n заданий для первых n очередей, а для других либо не запустятся вообще, либо запустятся не скоро (т.к. первые n висят в ожидании получения сообщений и “никогда” не заканчиваются).
Т.е. с помощью указанных менеджеров действительно можно ограничить потребления ресурсов сервером путем ограничения количество одновременно выполняемых регл. заданий, но только “обмен работать не будет”
Кроме того, указанные менеджеры не будут работать в случае если нужно ограничить ресурсы потребляемые заданиям из РАЗНЫХ БАЗ находящихся на одном сервере (см. мой пример в начале)

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

  1. Задания по получению сообщений не контролируются менеджером заданий, и висят постоянно (пусть их будет много)
  2. Логику в этих заданиях максимально упрощаем, т.е. задания по забору сообщений просто забирают текст сообщения и как есть складывают его в регистр (т.е. делаем максимально простую логику не нагружающую процессор)
  3. Разбор загруженных сообщений делаем с помощью отдельных заданий, контролируемых менеджером заданий (чтобы можно было ограничить ресурсы на эту операцию)

И/ИЛИ

  1. Есть отдельные задания, которые висят постоянно, не контролируются менеджером заданий и отвечают только за мониторинг сообщений в очередях (сами сообщения не забирают).
  2. Логика получения сообщений находиться в отдельных заданиях, контролируемых менеджером заданий. Эти задания считают данные порциями, чтобы освободить место следующим (т.е. прочитал 10 штук и все, а следующий экземпляр создается мониторющим заданием

Или может есть уже готовая логика применительно именно к задам обмена с их особенностью (нужно ждать сообщения)?

#16

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

#17

Технически в данном конкретном случае наверно так сделать можно. Согласен с тем, что заведомо лишнюю информацию отправлять не стоит.

Но с другой стороны это вроде противоречит идеям “событийной интеграции” о которой рассказывает @lustin т.к.

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

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

#18

Ок :slight_smile:

Отправляйте все, что и раньше. А вот при загрузке, пишите только если, изменилось :slight_smile:

Это и концептуально верно и нагрузку снизит.