Проблема OOM на уровне узла
Если память фактически контролируется только операционной системой на уровне узла, страдать может не только проблемный executor, но и соседние процессы. Диагностика при этом становится менее прозрачной: приложение видит падение, а команда платформы разбирает последствия уже после факта.
Три режима контроля памяти в YARN
В документации Hadoop хорошо видно, что есть несколько уровней зрелости: старый polling-контроль, strict enforcement через cgroups и elastic memory control через cgroups. Для рабочий контур важно не просто «убивать за память», а выбрать предсказуемый режим: где допускается burst, где контейнер должен быть остановлен, а где виртуальную память лучше не трогать из-за особенностей JVM.
Что дает LinuxContainerExecutor
LCE вместе с cgroups переводит контроль ближе к YARN-контейнеру. Это помогает не доводить ситуацию до хаотичного OOM на уровне узла и дает более честную модель: проблемный executor получает понятную границу, а платформа сохраняет управляемое поведение.
Как внедрять аккуратно
Практичный подход - включать LCE через явный feature flag в Ansible, менять минимальный набор файлов, отдельно проверять container-executor, cgroups hierarchy, pmem/vmem, elastic memory control и базовые проверки Spark/YARN. Клиенту не нужны простыни конфигов: ему важно увидеть, что изменение управляемое, откатываемое и подтверждается проверками.
Почему это важно для эксплуатации
Контроль памяти через LCE и cgroups - не косметика, а часть зрелой эксплуатационной модели YARN: проблемный контейнер должен иметь понятные границы, а платформа - предсказуемое поведение при превышении памяти.