Контейнер выходит за пределы памяти

В 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.

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

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

[...]

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

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

В mapred-site.xml:

mapreduce.map.memory.mb: 4096

mapreduce.reduce.memory.mb: 8192

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

В mapred-site.xml:

mapreduce.map.java.opts: -Xmx3072m

mapreduce.reduce.java.opts: -Xmx6144m

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

Подвести итог:

1. В YARN вы должны использовать mapreduceконфиги, а не mapredте. РЕДАКТИРОВАТЬ: этот комментарий больше не применим теперь, когда вы отредактировали свой вопрос.
2. То, что вы настраиваете, - это фактически то, сколько вы хотите запросить, а не то, какой максимум выделить.
3. Максимальные пределы настраиваются с помощью java.optsпараметров, перечисленных выше.

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

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

Примечание . Это происходит в 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>

У меня была действительно похожая проблема с использованием 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

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

При работе с искрой в EMR у меня была та же проблема, и настройки 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"
    }
  }
]

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

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

Запуск yarn в подсистеме Windows Linux с ОС Ubunto, ошибка «Выход за пределы виртуальной памяти, Убивающий контейнер». Я решил ее, отключив проверку виртуальной памяти в файле yarn-site.xml.

<property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property> 

Я лично не проверял, но ошибки hadoop-yarn-container-virtual-memory-понимание и решение-container-is-running -yond-virtual-memory-limits-errors звучат очень разумно

Я решил проблему, yarn.nodemanager.vmem-pmem-ratioустановив более высокое значение, и согласен с тем, что:

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