Контейнер працює за межами пам'яті

У 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 Гб пам’яті достатньо для мого завдання на карту / зменшення. Чому, коли я призначаю більше пам'яті контейнеру, завдання використовує більше? Це тому, що кожне завдання отримує більше розколів? Я вважаю, що ефективніше трохи зменшити розмір контейнера і створити більше контейнерів, щоб паралельно виконувалось більше завдань. Проблема полягає в тому, як я можу переконатися, що кожному контейнеру не буде призначено більше розділень, ніж він може обробити?

Слід також правильно налаштувати максимальний обсяг пам'яті для MapReduce. З цього підручника HortonWorks :

[...]

Кожна машина в нашому кластері має 48 ГБ оперативної пам'яті. Частина цієї оперативної пам'яті повинна бути> зарезервована для використання операційної системи. На кожному вузлі ми призначимо 40 ГБ оперативної пам’яті для> Пряжа для використання та збережемо 8 ГБ для операційної системи

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

У 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, яке описує подібну проблему (і рішення).

Існує перевірка на рівні пряжі щодо коефіцієнта використання віртуальної та фізичної пам’яті. Проблема полягає не тільки в тому, що у ВМ недостатньо фізичної пам’яті. Але це тому, що використання віртуальної пам'яті більше, ніж очікувалося для даної фізичної пам’яті.

Примітка : Це відбувається на Centos / RHEL 6 через його агресивне розподіл віртуальної пам'яті.

Це може бути вирішено:

1. Вимкніть перевірку використання віртуальної пам’яті, встановивши yarn.nodemanager.vmem-check-enabled на false ;

2. Збільште співвідношення VM: PM, встановивши коефіцієнт yarn.nodemanager.vmem-pmem на деяке вище значення.

Список літератури :

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"
    }
  }
]

З цим питанням ми також стикалися нещодавно. Якщо проблема пов'язана з пам'яттю картографа, я хотів би запропонувати кілька речей, які потрібно перевірити.

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

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

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

Я особисто не перевіряв, але hadoop-yarn-контейнер-віртуальна пам’ять-розуміння-і-вирішення-контейнер-працює-поза-обмеженнями-віртуальної пам'яті звучить дуже розумно

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

Іншим менш рекомендованим рішенням є вимкнення перевірки віртуальної пам'яті, встановивши для yarn.nodemanager.vmem-check-enabled значення false.