Гибкое распределение пространства кучи в Hadoop MapReduce Задачи Mapper

Question

У меня возникли проблемы с поиском наилучшего способа настройки моего кластера Hadoop (CDH4), работающего с MapReduce1. Я в ситуации, когда мне нужно запустить оба mappers, которым требуется такое большое количество кучи Java-кучи, что я не мог бы запустить более 1 mapper на узел, но в то же время я хочу иметь возможность запускать задания которые могут извлечь выгоду из многих карт на узел.

Я настраиваю кластер через интерфейс управления Cloudera, а Max Map Tasks и mapred.map.child.java.opts выглядят довольно статическими.

То, что я хотел бы иметь, - это что-то вроде пула пространства кучи с доступным X GB, который будет учитывать оба вида заданий без необходимости перенастраивать службу MapReduce каждый раз. Если я запустил 1 mapper, он должен назначить кучу XGB - если я запустил 8 карт, он должен назначить кучу X/8 GB.

Я рассмотрел как максимальную виртуальную память, так и пределы памяти компактной/жесткой памяти группы, но ни один из них не даст мне именно то, что я хочу. Максимальная виртуальная память не эффективна, поскольку она по-прежнему является заданием каждой задачи. Параметр Cgroup является проблематичным, поскольку на самом деле он не ограничивает отдельные задачи меньшим количеством кучи, если их больше, но, скорее, позволит задаче использовать слишком много памяти, а затем убить процесс, когда это произойдет.

Можно ли настроить поведение, которое я хочу достичь?

Answer 1

(PS Вы должны использовать новое имя этого свойства с Hadoop 2/CDH4: mapreduce.map.java.opts Но оба должны еще быть признаны.).

Значение настройки в кластере просто по умолчанию. Его можно переопределить на основе работы. Вы должны оставить значение по умолчанию из CDH или настроить его на что-то разумное для обычных картографов.

Для вашего задания с высокой памятью, в вашем коде клиента, установите mapreduce.map.java.opts в свой Configuration объект для Job, прежде чем отправить его.

Ответ становится более сложным, если вы используете MR2/YARN, поскольку он больше не планирует по «слотам», а в контейнере. Таким образом, память вводит изображение новым, другим способом с новыми, разными свойствами. (Меня это смущает, и я даже в Cloudera.)

В некотором роде было бы лучше, потому что вы выражаете свои требования к ресурсам с точки зрения памяти, что хорошо здесь. Вы бы установили mapreduce.map.memory.mb, а размер на 30% больше, чем размер кучи JVM, так как это память, доступная для всего процесса. Точно так же вы ставите выше для работы с высокой памятью. Затем Hadoop может решить, сколько маршрутизаторов запустить, и решить, где разместить рабочих для вас, и использовать как можно больше кластера для вашей конфигурации. Нет суеты с вашим собственным воображаемым пулом ресурсов.

В MR1 это сложнее добиться. Концептуально вы хотите установить максимальное количество картографов на одного работника на 1 через mapreduce.tasktracker.map.tasks.maximum вместе с настройкой кучи, но только для работы с высокой памятью. Я не знаю, может ли клиент запросить или установить это, хотя на основе работы. Я сомневаюсь, что это не будет иметь никакого смысла. Вы не можете реально подойти к этому, контролируя количество картографов только потому, что вам нужно взломать, чтобы даже узнать, не говоря уже о контроле, количество отображаемых им карт.

Я не думаю, что настройки уровня OS помогут. В некотором роде они напоминают больше о том, как MR2/YARN думает о планировании ресурсов. Лучше всего (перейдите к MR2 и) используйте средства управления ресурсами MR2 и дайте понять, что остальное.