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

Question

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

Answer 1

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

[...]

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

Для нашего примера кластера у нас есть минимальная оперативная память для контейнера (yarn.scheduler.minimum-allocation-mb) = 2 ГБ. Таким образом, мы назначим 4 ГБ для Контейнеров задач Map и 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

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

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

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

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

Answer 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>

Answer 3

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

Тем не менее, то, что в итоге работало tez.am.resource.memory.mb, например:

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

• Проверьте , включен ли комбайнер или нет? Если да, то это означает, что логика сокращения должна выполняться для всех записей (вывод mapper). Это происходит в памяти. На основе вашего приложения вам нужно проверить, помогает ли включение комбайнера или нет. Компромисс находится между байтами передачи по сети и затраченным временем / памятью / ЦП для логики уменьшения количества записей "X".
  • Если вы чувствуете, что объединитель не имеет большой ценности, просто отключите его.
  • Если вам нужен объединитель, а 'X' - огромное число (скажем, миллионы записей), тогда подумайте об изменении логики разделения (для форматов ввода по умолчанию используйте меньший размер блока, обычно 1 размер блока = 1 разделение), чтобы отобразить меньшее количество записей в одиночный картограф
• Number of records getting processed in a single mapper. Remember that all these records need to be sorted in memory (output of mapper is sorted). Consider setting mapreduce.task.io.sort.mb (default is 200MB) to a higher value if needed. mapred-configs.xml
• If any of the above didn't help, try to run the mapper logic as a standalone application and profile the application using a Profiler (like JProfiler) and see where the memory getting used. This can give you very good insights.

Answer 8

I am practicing Hadoop programs (version hadoop3). Via virtual box I have installed Linux OS. We allocate very limited memory at time of installation of Linux. By setting the following memory limit properties in mapred-site.xml and restarting your HDFS and YARN then my program worked.

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

Answer 9

Я лично не проверял, но http://cloudsqale.com/2020/02/19/hadoop-yarn-container-virtual-memory-understanding-and-solving-container-is-running-beyond-virtual-memory-limits-errors/ звучит очень разумно

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

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