Как решить задачу определения равномерности загрузки кластера?

Question

[Snowindy]

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

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

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



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

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

Answer 1

[Dimonchik]

проектов нет - ибо программисты пишут корректный алгоримтически и программно грамотный код

пишут же?

а так - APM сервисы, new relic и иже с ними

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

Comments

[Snowindy]

Простите, вы вообще вопрос читали?

[Dimonchik]

Snowindy, прощаю

если непонятно мое разъяснение - пишите свое неэкстраординарное

Answer 2

[⚡ Kotobotov ⚡]

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

Comments

[Snowindy]

После разработки и запуска задачи, естественно, специалист смотрит производительность и тюнит алгоритм. Но, запуская этот же код на данных другого клиента, или на данных этого же клиента в другое время, можно обнаружить, что из-за data skewness или чего-то подобного - кластер впустую тратит деньги.

Таким образом, у нас сотни запусков N алгоритмов на M клиентах в разное время T. Как в этом случае понять, куда должен идти копать наш специалист со всеми своими инструментами?

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

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

[⚡ Kotobotov ⚡]

Snowindy, говорю же есть SparkUI там это все наглядно видно.

[Snowindy]

⚡ Kotobotov ⚡, там есть числовая метрика равномерности использования слейвов, правда?

Или вы предлагаете мне метрики со спарка взять и с ними работать? Так метрики - не проблема абсолютно, хоть с прометея, хоть с spark UI, хоть с ганглии - забрать - это вопрос техники. Проблема - аналитический механизм превращения графиков с разных нод в скалярное число, индекс равномерности.

Я ищу такую библиотеку или продукт, чтобы самому не писать. Как и написал в вопросе.

[⚡ Kotobotov ⚡]

Snowindy,
>Проблема - аналитический механизм превращения графиков с разных нод в скалярное число, индекс равномерности.

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

[Snowindy]

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

Это надо компании, чтобы в итоге сэкономить деньги, и заплатить годовой бонус разработчику. У которого вообще никаких проблем нет, кроме эмпатии.

[⚡ Kotobotov ⚡]

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

[Snowindy]

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

Но даже если кластер шарится между джобами - находить места проблем не руками - это важно и нужно.