Как изменить поведение балансировки нагрузки, которое Jenkins использует для управления ведомыми устройствами?

Мы используем Jenkins для нашей системы сборки CI. Мы также используем «одновременные сборки»; так что Дженкинс будет строить каждое изменение независимо. Это означает, что мы часто выполняем 5 или 6 сборок одной и той же работы одновременно. Для этого у нас есть 4 раба каждый с 12 исполнителями.

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

Есть ли плагин или что-то, что изменяет поведение балансировки нагрузки, которое Дженкинс использует для управления своими подчиненными?

Ответы на вопрос(4)

Плагин Throttle Concurrent Builds ограничить количество экземпляров задания, которые могут выполняться параллельно на одном узле

который изменяет балансировщик нагрузки в Jenkins, чтобы выбрать узел, который в настоящее время имеет наименьшую нагрузку -https://wiki.jenkins-ci.org/display/JENKINS/Least+Load+Plugin

Любые отзывы приветствуются.

 15 янв. 2016 г., 23:49
Большое спасибо! Последняя дата сборки плагина в настоящее время - «27 июня 2013». Совместим ли он с более новыми версиями Jenkins, например 1.625.3?
 18 янв. 2016 г., 20:41
еще раз спасибо, я попробую!
 18 янв. 2016 г., 16:52
Должно быть, я сейчас использую его с 1.625.2

зачем настраивать их на 12 исполнителей? Если это действительно так, вы должны уменьшить количество исполнителей до 1. У моего Jenkins есть 30 рабов, у каждого по 1 исполнителю.

 Jay Spang20 июн. 2012 г., 20:12
Наши подчиненные Jenkins выполняют много задач, одной из которых является компиляция нашего кода. У рабов 12 исполнителей, потому что он может делать 12 вещей одновременно (сборки являются «самыми большими» из этих вещей). Он может даже запускать 4-5 сборок просто отлично, он просто замедляет работу (и мы хотим, чтобы отзывы об этих сборках были максимально быстрыми). Сокращая количество этих подчиненных до 1 исполнителя, мы получаем 15 ядер, которые простаивают большую часть дня, что не очень эффективно использует ресурсы.
Решение Вопроса

который делает это автоматически, вот идея, что вы можете сделать:

Install Node Label Parameter plugin Add SLAVE parameter to your jobs Restrict jobs to run on ${SLAVE}

Add a trigger job that will do the following:

Analyze load distribution via a System Groovy Script and decide on which node to start next build. Dispatch the build on that node with Parametertized Trigger plugin by assigning appropriate value to SLAVE parameter.

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

 Jay Spang22 июн. 2012 г., 01:26
Там, кажется, не существует плагин, который делает это (что я могу найти). Хотя это предположение намного больше ... "вовлечено" чем просто с помощью плагина, это выглядит как наш лучший вариант!

Ваш ответ на вопрос