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

85

В 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. Почему, когда я выделяю контейнеру больше памяти, задача использует больше? Это потому, что каждая задача получает больше разделений? Я считаю, что более эффективно немного уменьшить размер контейнера и создать больше контейнеров, чтобы больше задач выполнялось параллельно. Проблема в том, как я могу убедиться, что каждому контейнеру не будет назначено больше разделений, чем он может обработать?

Лишу
источник
Привет ! ваш конфиг 'yarn.nodemanager.vmem-pmem-ratio = 2'?
спрайт

Ответы:

102

Вы также должны правильно настроить максимальное выделение памяти для 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, который описывает аналогичную проблему (и решение).

кабада
источник
Да. Установив mapreduce.map.java.optsи mapreduce.reduce.java.optsрешив мою проблему. Знаете ли вы, что фактическая память, назначенная задаче, определяется только mapreduce.map/reduce.memory.mb? Как yarn.scheduler.minimum-allocation-mbвлияет на фактическое назначение памяти?
Lishu
@lishu, если это помогло, примите ответ. Что касается вашего последнего вопроса, настройка пряжи применяется к любому распределению контейнеров в кластере; это включает задачи сопоставления и сокращения, но также и другие задачи из других типов приложений. Настройки mapreduce применяются только к заданиям mapreduce.
cabad
@cabad, я разрабатываю библиотеку, которую использует Lishu. Мне было интересно, измените ли вы что-нибудь в своем ответе, зная, что задача MR порождает процесс, который фактически выделяет большую часть памяти (потоковая передача hadoop). Конечно, настройка Xmx не влияет на внешний процесс, поскольку это не Java-программа. Спасибо за вашу помощь.
пикколбо
2
Теперь есть удобный инструмент от Hortonworks под названием hdp-configuration-utils для получения рекомендуемых значений. Получите его с github.com/hortonworks/hdp-configuration-utils
продавец
1
Если применение правильной конфигурации памяти не устранило проблему (например, в моем случае, на самом деле она работала с hasoop, запущенным на ubuntu, но не на CentOS), попробуйте отключить проверку vmem
Bakhshi
47

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

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

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

хиропротагонист
источник
Гм @hiroprotagonist, знаете ли вы, должна ли «настройка» параметра пряжи происходить до запуска YARN или она используется только во время приложения (и может быть изменена при переходе от одного задания к другому)?
Судья Ментал
1
я смог установить во время подачи заявки. в частности, в интерактивной консоли улья.
хиропротагонист 07
8

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

Брайан Джи
источник
1

При работе с искрой в 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"
    }
  }
]
пандорабоб
источник
1

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

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

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

<property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property> 
Санджай Сингх
источник
В WSL сообщение об ошибке имеет абсурдные числа (по крайней мере, для меня): «... выходит за рамки ограничений виртуальной памяти. Текущее использование: 338,8 МБ из 2 ГБ физической памяти; используется 481,1 ГБ из 4,2 ГБ виртуальной памяти. Убивающий контейнер . "
Samik R
@SamikR Да, у меня похожая ситуация, я думаю, это не проблемы с HADoop, а проблемы с WSL. Возможно, мне нужно перенести демонстрацию на настоящий компьютер с ОС Linux
Bingoabs
0

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

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

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

Сида Чжоу
источник