Как стать автором
Обновить

ОС против Kafka: битва за map-области: история одного неочевидного лимита

Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров2.7K
Всего голосов 6: ↑6 и ↓0+6
Комментарии4

Комментарии 4

Интересно как они смогли упасть все сразу. Там что, на столько равномерно все было сбалансированно? Или поздно среагировали?

Добрый день! Ситуация такая что нод всего три и фактор репликации стоит 3, соответственно на всех трех нодах данные одинаковые, отсюда и ~ одинаковое кол-во сегментов и из этого же следует что количество memory-mapped областей на всех нодах меняется очень сходно, практически одинаково в рамках процесса Kafka. Ну и соответственно за рамки дефолтного придела все ноды вышли в примерно одно и тоже время - почему и упали также +- в одно время с разницей в пару минут.

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

Ну устойчивую архитектуру от всего наверно сложно построить, тут скорее вопрос целесообразности, ведь от увеличения кол-ва девяток после запятой в SLA стоимость решения растет и далеко не линейно)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации