Size: a a a

2021 March 04

N

Nikita Blagodarnyy in Data Engineers
Uncel Duk
Есть крутилка у ведра
Тут про что речь?
источник

A

Alex in Data Engineers
Просто если у вас нету оверкомита, то ярн свои джобы будет держать в указанных пределах

Дальше 2 варианта
1. Если без cgroups то просто процесс убивается(но он трекает по таймеру, в пике можно и больше сожрать, главное не попасться и успеть вернуть)
2. Если с cgroups то как раз будет невозможность алоцировать память (ядро не даст процессу больше чем на него лимиты стоят)
источник

UD

Uncel Duk in Data Engineers
Nikita Blagodarnyy
Тут про что речь?
vm.max_map_count
источник

A

Alex in Data Engineers
Я бы посмотрел в этот момент в логах мастера, так как в логах контейнера пусто и там просто процесс убит
источник

A

Alex in Data Engineers
А вот в мастере уже можно найти инфу что попытка алокации больше чем разрешено
источник

N

Nikita Blagodarnyy in Data Engineers
Alex
Просто если у вас нету оверкомита, то ярн свои джобы будет держать в указанных пределах

Дальше 2 варианта
1. Если без cgroups то просто процесс убивается(но он трекает по таймеру, в пике можно и больше сожрать, главное не попасться и успеть вернуть)
2. Если с cgroups то как раз будет невозможность алоцировать память (ядро не даст процессу больше чем на него лимиты стоят)
Когда вы говорите про оверкоммит, имеется ввиду spark.executor.memoryOverhead?
Я как-то не сталкивался с оверкоммитом памяти в ярне, только с vcores.
источник

A

Alex in Data Engineers
Нет, я говорю что в хадупе при настройке ярна можно указать памяти больше на нодаменеджере чем действительно есть

То есть мы знаем что джобы не выжирает обычно все. Следовательно модем на машине в 10гб сказать что ярн располагает 12гб

Если свопа нету, то в какой-то момент может случится ситуация что всем не хватит и кто-то упадёт

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

A

Alex in Data Engineers
Да, из той же оперы что vcores
источник

A

Alex in Data Engineers
Но cpu более эластичен чем память :)
источник

A

Alex in Data Engineers
Поэтому уточнил на всякий случай
источник

A

Alex in Data Engineers
Вообще как уже говорил я бы проверил сразу логи на драйвере почему умирает воркер, не помню про спарк, но в моём апп мастере я регулярно вижу как парни запрашивают один контейнер под кернел, а потом выжирает и он падает
источник

N

Nikita Blagodarnyy in Data Engineers
Alex
Нет, я говорю что в хадупе при настройке ярна можно указать памяти больше на нодаменеджере чем действительно есть

То есть мы знаем что джобы не выжирает обычно все. Следовательно модем на машине в 10гб сказать что ярн располагает 12гб

Если свопа нету, то в какой-то момент может случится ситуация что всем не хватит и кто-то упадёт

Видел такие настройки и по памяти и по cpu. Чтобы поднять общий уровень утилизации. Так как частенько воркеры стоят ожидая следующих команд
Не, таким не балуемся. NM выдано меньше, чем физической  + еще под ОС и прочее оставлено.
источник

A

Alex in Data Engineers
Лог контейнера будет пустой, максимум в ноде менеджер логе можно что-то найти
источник

A

Alex in Data Engineers
Ещё полезно посмотреть мониторинг памяти уже самой ноды

вы думаете что это память, а там откажется что занято только 80%
источник

АЖ

Андрей Жуков... in Data Engineers
Alex
Ещё полезно посмотреть мониторинг памяти уже самой ноды

вы думаете что это память, а там откажется что занято только 80%
Какие-нибудь зомби-запилины или жупитеры легко
источник

A

Alex in Data Engineers
Да
источник

A

Alex in Data Engineers
Поэтому посмотреть инфу по ноде

Посмотреть логи мастера/драйвера и логи ноды
источник

N

Nikita Blagodarnyy in Data Engineers
Хотя про оверкоммит идея интересная. Машины в кластере разные, а настройки нодменеджеров могли раскатать одинаковые. Тогда там, где меньше памяти, может получаться тот самый оверкоммит.
источник

АЖ

Андрей Жуков... in Data Engineers
Nikita Blagodarnyy
Хотя про оверкоммит идея интересная. Машины в кластере разные, а настройки нодменеджеров могли раскатать одинаковые. Тогда там, где меньше памяти, может получаться тот самый оверкоммит.
а вот и колено нашлось
источник

E

Evgeny in Data Engineers
Nikita Blagodarnyy
Хотя про оверкоммит идея интересная. Машины в кластере разные, а настройки нодменеджеров могли раскатать одинаковые. Тогда там, где меньше памяти, может получаться тот самый оверкоммит.
кажется, что правильный путь - уходить от хардкода памяти\ядер и динамически считать все это дело с помощью ansible\salt\puppet
источник