ну если все время 100%, то вероятно свое железо дешевле будет. Я думал будет батчевая нагрузка: подняли - посчитали - убили

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

ок, подловил. не 100%, а 77-85%
памяти на узлах 300 гб

ну а сколько свободно?

а это тут причем ? там импала большую часть жрет

собсно две команды: cat /proc/loadavg и free -h

сейчас у нее выходной

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

ну значит там сотни складов, тысячи точек продаж, всякие crm системы, бухгалтерия. все это валит 24/7

валит может и 24/7, но головной офис хочет видеть отчетность к 9 утра по мск

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

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

- вы можете запустить 10 джобов параллельно, на 10 цпу, или последовательно, на 1 цпу

вопросы:
1. будет ли разница в цене?
2. нужно ли оставлять ЦПУ работать вхолостую в случае параллельного запуска когда джобы выполнены?

1) разницы как я понимаю не будет
2) ЦПУ вхолостую работать не будет ни в один момент времени. если задач меньше, можно узлов оставить столько, сколько треюует ситуация

еще раз, 10 джобов параллель быстро обработают очередь, но никогда не смогут всю обработать. сотни источников, в каждые 2-3 секунды что-то присылают. какую бы ты не забубенил параллельность, уже через 2-3 секунды прилетит еще что-то

У вас каждой сообщение из потокового источника вызывает пересчёт всех витрин, требуют всего кластера?

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

В общем we agree to disagree, интересно будет послушать про ваш опыт достижения 100% утилизации в хадупе, сбережете сообществу разработку всех этих улучшений в области opportunistic containers

Кстати про странные архитектуры и решения, всем интересующимся отраслью в широком смысле рекомендую посмотреть на свежий радар, там есть интересные движения по нашим темам

на это все есть какоето sla? как его гарантировать при такой нагрузке?

ну эта нагрузка то потому что могём, а не потому что реально надо