Тут про что речь?

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

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

vm.max_map_count

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

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

Когда вы говорите про оверкоммит, имеется ввиду spark.executor.memoryOverhead?
Я как-то не сталкивался с оверкоммитом памяти в ярне, только с vcores.

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

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

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

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

Да, из той же оперы что vcores

Но cpu более эластичен чем память :)

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

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

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

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

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

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

Какие-нибудь зомби-запилины или жупитеры легко

Да

Поэтому посмотреть инфу по ноде

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

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

а вот и колено нашлось

кажется, что правильный путь - уходить от хардкода памяти\ядер и динамически считать все это дело с помощью ansible\salt\puppet