Подтвердить что ты не робот

Контейнер работает за пределами памяти

В Hadoop v1 я назначил каждый 7 слотов для картператора и редуктора размером 1 ГБ, мои картографы и редукторы работают нормально. Моя машина имеет 8G памяти, 8 процессоров. Теперь с YARN, когда вы запускаете одно и то же приложение на одной машине, я получил ошибку контейнера. По умолчанию у меня есть следующие настройки:

  <property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>1024</value>
  </property>
  <property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>8192</value>
  </property>
  <property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>8192</value>
  </property>

Это дало мне ошибку:

Container [pid=28920,containerID=container_1389136889967_0001_01_000121] is running beyond virtual memory limits. Current usage: 1.2 GB of 1 GB physical memory used; 2.2 GB of 2.1 GB virtual memory used. Killing container.

Затем я попытался установить ограничение памяти в mapred-site.xml:

  <property>
    <name>mapreduce.map.memory.mb</name>
    <value>4096</value>
  </property>
  <property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>4096</value>
  </property>

Но все еще возникает ошибка:

Container [pid=26783,containerID=container_1389136889967_0009_01_000002] is running beyond physical memory limits. Current usage: 4.2 GB of 4 GB physical memory used; 5.2 GB of 8.4 GB virtual memory used. Killing container.

Я смущен, почему задача карты нуждается в такой большой памяти. По моему мнению, для моей задачи map/reduce достаточно 1 ГБ памяти. Почему, поскольку я назначаю больше памяти контейнеру, задача использует больше? Это потому, что каждая задача получает больше расколов? Я чувствую, что более эффективно уменьшить размер контейнера немного и создать больше контейнеров, чтобы больше задач выполнялось параллельно. Проблема в том, как я могу убедиться, что каждому контейнеру не будет назначено больше разделов, чем он может обрабатывать?

4b9b3361

ОТВЕТЫ

Ответ 1

Вы также должны правильно настроить максимальные выделения памяти для MapReduce. Из этого учебника по HortonWorks:

[...]

Каждая машина в нашем кластере имеет 48 ГБ оперативной памяти. Часть этой оперативной памяти должна быть зарезервирована для использования операционной системой. На каждом узле выделите 40 ГБ ОЗУ для использования> YARN и оставьте 8 ГБ для операционной системы

Для нашего примера кластера у нас есть минимальная оперативная память для контейнера (yarn.scheduler.minimum-allocation-mb) = 2 ГБ. Ну при этом назначьте 4 гб для Контейнеров задач карты и 8 ГБ для Контейнеров задач Сокращения.

In mapred-site.xml:

mapreduce.map.memory.mb: 4096

mapreduce.reduce.memory.mb: 8192

Каждый контейнер будет запускать JVM для задач Map и Reduce. JVM Размер кучи должен быть установлен ниже, чем Map и Reduce memory определены выше, так что они находятся в пределах контейнера память выделена YARN.

In mapred-site.xml:

mapreduce.map.java.opts: -Xmx3072m

mapreduce.reduce.java.opts: -Xmx6144m

Приведенные выше настройки настраивают верхний предел физической памяти, который Задачи Map и Reduce будут использовать.

Подводя итог:

  1. В YARN вы должны использовать конфиги mapreduce, а не mapred. ОБНОВЛЕНИЕ: Этот комментарий больше не применяется, когда вы отредактировали свой вопрос.
  2. На самом деле вы конфигурируете то, сколько вы хотите запросить, а не то, что максимум можно выделить.
  3. Максимальные пределы настраиваются с помощью настроек java.opts, перечисленных выше.

Наконец, вы можете проверить этот другой SO вопрос, описывающий аналогичную проблему (и решение).

Ответ 2

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

Примечание. Это происходит в Centos/RHEL 6 из-за агрессивного выделения виртуальной памяти.

Это можно решить одним из следующих способов:

  1. Отключите проверку использования виртуальной памяти, установив yarn.nodemanager.vmem-check-enabled до false;

  2. Увеличьте соотношение VM: PM, установив для yarn.nodemanager.vmem-pmem-ratio более высокое значение.

Ссылки :

https://issues.apache.org/jira/browse/HADOOP-11364

http://blog.cloudera.com/blog/2014/04/apache-hadoop-yarn-avoiding-6-time-consuming-gotchas/

Добавьте следующее свойство в yarn-site.xml

 <property>
   <name>yarn.nodemanager.vmem-check-enabled</name>
    <value>false</value>
    <description>Whether virtual memory limits will be enforced for containers</description>
  </property>
 <property>
   <name>yarn.nodemanager.vmem-pmem-ratio</name>
    <value>4</value>
    <description>Ratio between virtual memory to physical memory when setting memory limits for containers</description>
  </property>

Ответ 3

У меня была очень похожая проблема с использованием HIVE в EMR. Ни один из существующих решений не работал у меня - т.е. Ни одна из конфигураций mapreduce не работала для меня; и не устанавливал значение yarn.nodemanager.vmem-check-enabled на false.

Однако в итоге работала установка tez.am.resource.memory.mb, например:

hive -hiveconf tez.am.resource.memory.mb=4096

Еще одна настройка для настройки - yarn.app.mapreduce.am.resource.mb

Ответ 4

Я не могу прокомментировать принятый ответ из-за низкой репутации. Однако я хотел бы добавить, что это по дизайну. NodeManager убивает ваш контейнер. Похоже, вы пытаетесь использовать потоки хаопов, которые выполняются как дочерний процесс задачи уменьшения карты. NodeManager контролирует все дерево процессов задачи, и если он потребляет больше памяти, чем максимальный набор в mapreduce.map.memory.mb или mapreduce.reduce.memory.mb соответственно, мы ожидаем, что Nodemanager убьет задачу, иначе ваша задача заключается в краже памяти, принадлежащей другим контейнерам, которые вам не нужны.

Ответ 5

Во время работы с искрами в ЭМИ у меня была та же проблема, и установка maximizeResourceAllocation=true сделала трюк; надеюсь, что это помогает кому-то. Вы должны установить его при создании кластера. Из Документы EMR:

aws emr create-cluster --release-label emr-5.4.0 --applications Name=Spark \
--instance-type m3.xlarge --instance-count 2 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/mybucket/myfolder/myConfig.json

Где myConfig.json должен сказать:

[
  {
    "Classification": "spark",
    "Properties": {
      "maximizeResourceAllocation": "true"
    }
  }
]

Ответ 6

Мы также столкнулись с этой проблемой недавно. Если проблема связана с памятью картографа, я хотел бы предложить несколько вещей, которые необходимо проверить.

  • Проверить, включен ли комбайнер, или нет? Если да, то это означает, что логика сокращения должна выполняться для всех записей (вывод mapper). Это происходит в памяти. В зависимости от вашего приложения вам нужно проверить, помогает ли включение объединителя или нет. Компромисс между байтами передачи по сети и затраченным временем/памятью/ЦП для логики уменьшения количества записей "Х".
    • Если вы считаете, что объединитель не имеет большой ценности, просто отключите его.
    • Если вам нужен объединитель, а 'X' - огромное число (скажем, миллионы записей), тогда подумайте об изменении логики разделения (для форматов ввода по умолчанию используйте меньший размер блока, обычно 1 размер блока = 1 разделение), чтобы отобразить меньшее количество записей в один картограф.
  • Количество обрабатываемых записей в одном маппере. Помните, что все эти записи должны быть отсортированы в памяти (выходные данные mapper отсортированы). Попробуйте установить для mapreduce.task.io.sort.mb (по умолчанию 200 МБ) более высокое значение, если это необходимо. mapred-configs.xml
  • Если что-то из вышеперечисленного не помогло, попробуйте запустить логику отображения как отдельное приложение и профилировать приложение с помощью Profiler (например, JProfiler) и посмотреть, где используется память. Это может дать вам очень хорошее понимание.