Как настроить параметры Hadoop MapReduce в Amazon EMR?

Моя работа MR закончилась на карте 100% уменьшение 35% с большим количеством сообщений об ошибках, похожих на running beyond physical memory limits. Current usage: 3.0 GB of 3 GB physical memory used; 3.7 GB of 15 GB virtual memory used. Killing container.

Мой входной *.bz2 файл имеет размер около 4 ГБ, если я его распакую, размер будет около 38 ГБ, на выполнение этого задания с one Master и two slavers на Amazon EMR ушло около часа.

Мои вопросы:
- Почему эта работа использовала так много памяти?
- Почему эта работа заняла около часа? Обычно выполняется задание подсчета слов объемом 40 ГБ на небольшом 4 -node cluster занимает около 10 минут.
- Как настроить параметры MR для решения этой проблемы?
- Что Типы инстансов Amazon EC2 подходят для решения этой проблемы?

См. Следующий журнал:
- Снимок физической памяти (байты) = 43327889408 => 43.3GB
- Снимок виртуальной памяти (байты) = 108950675456 => 108.95GB
- Общее зафиксированное использование кучи (байты) = 34940649472 => 34.94GB

Я предлагаю следующие решения, но я не уверен, верны они или нет
- используйте более крупный инстанс Amazon EC2 с объемом памяти не менее 8 ГБ
- настройте MR параметры с использованием следующих кодов

Версия 1:

Configuration conf = new Configuration();
Job job = Job.getInstance(conf, "jobtest1");
//don't kill the container, if the physical memory exceeds "mapreduce.reduce.memory.mb" or "mapreduce.map.memory.mb"
conf.setBoolean("yarn.nodemanager.pmem-check-enabled", false);
conf.setBoolean("yarn.nodemanager.vmem-check-enabled", false);

Версия 2:

Configuration conf = new Configuration();
Job job = Job.getInstance(conf, "jobtest2");
//conf.set("mapreduce.input.fileinputformat.split.minsize","3073741824");                                                                   
conf.set("mapreduce.map.memory.mb", "8192");                                     
conf.set("mapreduce.map.java.opts", "-Xmx6144m");                                         
conf.set("mapreduce.reduce.memory.mb", "8192");                                         
conf.set("mapreduce.reduce.java.opts", "-Xmx6144m");                                             

Бревно:

15/11/08 11:37:27 INFO mapreduce.Job:  map 100% reduce 35%
15/11/08 11:37:27 INFO mapreduce.Job: Task Id : attempt_1446749367313_0006_r_000006_2, Status : FAILED
Container [pid=24745,containerID=container_1446749367313_0006_01_003145] is running beyond physical memory limits. Current usage: 3.0 GB of 3 GB physical memory used; 3.7 GB of 15 GB virtual memory used. Killing container.
Dump of the process-tree for container_1446749367313_0006_01_003145 :
    |- PID PPID PGRPID SESSID CMD_NAME USER_MODE_TIME(MILLIS) SYSTEM_TIME(MILLIS) VMEM_USAGE(BYTES) RSSMEM_USAGE(PAGES) FULL_CMD_LINE
    |- 24745 24743 24745 24745 (bash) 0 0 9658368 291 /bin/bash -c /usr/lib/jvm/java-openjdk/bin/java -Djava.net.preferIPv4Stack=true -Dhadoop.metrics.log.level=WARN  -Xmx2304m -Djava.io.tmpdir=/mnt1/yarn/usercache/ec2-user/appcache/application_1446749367313_0006/container_1446749367313_0006_01_003145/tmp -Dlog4j.configuration=container-log4j.properties -Dyarn.app.container.log.dir=/var/log/hadoop-yarn/containers/application_1446749367313_0006/container_1446749367313_0006_01_003145 -Dyarn.app.container.log.filesize=0 -Dhadoop.root.logger=INFO,CLA org.apache.hadoop.mapred.YarnChild **.***.***.*** 32846 attempt_1446749367313_0006_r_000006_2 3145 1>/var/log/hadoop-yarn/containers/application_1446749367313_0006/container_1446749367313_0006_01_003145/stdout 2>/var/log/hadoop-yarn/containers/application_1446749367313_0006/container_1446749367313_0006_01_003145/stderr  
    |- 24749 24745 24745 24745 (java) 14124 1281 3910426624 789477 /usr/lib/jvm/java-openjdk/bin/java -Djava.net.preferIPv4Stack=true -Dhadoop.metrics.log.level=WARN -Xmx2304m -Djava.io.tmpdir=/mnt1/yarn/usercache/ec2-user/appcache/application_1446749367313_0006/container_1446749367313_0006_01_003145/tmp -Dlog4j.configuration=container-log4j.properties -Dyarn.app.container.log.dir=/var/log/hadoop-yarn/containers/application_1446749367313_0006/container_1446749367313_0006_01_003145 -Dyarn.app.container.log.filesize=0 -Dhadoop.root.logger=INFO,CLA org.apache.hadoop.mapred.YarnChild **.***.***.*** 32846 attempt_1446749367313_0006_r_000006_2 3145 

Container killed on request. Exit code is 143
Container exited with a non-zero exit code 143

15/11/08 11:37:28 INFO mapreduce.Job:  map 100% reduce 25%
15/11/08 11:37:30 INFO mapreduce.Job:  map 100% reduce 26%
15/11/08 11:37:37 INFO mapreduce.Job:  map 100% reduce 27%
15/11/08 11:37:42 INFO mapreduce.Job:  map 100% reduce 28%
15/11/08 11:37:53 INFO mapreduce.Job:  map 100% reduce 29%
15/11/08 11:37:57 INFO mapreduce.Job:  map 100% reduce 34%
15/11/08 11:38:02 INFO mapreduce.Job:  map 100% reduce 35%
15/11/08 11:38:13 INFO mapreduce.Job:  map 100% reduce 36%
15/11/08 11:38:22 INFO mapreduce.Job:  map 100% reduce 37%
15/11/08 11:38:35 INFO mapreduce.Job:  map 100% reduce 42%
15/11/08 11:38:36 INFO mapreduce.Job:  map 100% reduce 100%
15/11/08 11:38:36 INFO mapreduce.Job: Job job_1446749367313_0006 failed with state FAILED due to: Task failed task_1446749367313_0006_r_000001
Job failed as tasks failed. failedMaps:0 failedReduces:1

15/11/08 11:38:36 INFO mapreduce.Job: Counters: 43
    File System Counters
        FILE: Number of bytes read=11806418671
        FILE: Number of bytes written=22240791936
        FILE: Number of read operations=0
        FILE: Number of large read operations=0
        FILE: Number of write operations=0
        HDFS: Number of bytes read=16874
        HDFS: Number of bytes written=0
        HDFS: Number of read operations=59
        HDFS: Number of large read operations=0
        HDFS: Number of write operations=0
        S3: Number of bytes read=3942336319
        S3: Number of bytes written=0
        S3: Number of read operations=0
        S3: Number of large read operations=0
        S3: Number of write operations=0
    Job Counters 
        Failed reduce tasks=22
        Killed reduce tasks=5
        Launched map tasks=59
        Launched reduce tasks=27
        Data-local map tasks=59
        Total time spent by all maps in occupied slots (ms)=114327828
        Total time spent by all reduces in occupied slots (ms)=131855700
        Total time spent by all map tasks (ms)=19054638
        Total time spent by all reduce tasks (ms)=10987975
        Total vcore-seconds taken by all map tasks=19054638
        Total vcore-seconds taken by all reduce tasks=10987975
        Total megabyte-seconds taken by all map tasks=27438678720
        Total megabyte-seconds taken by all reduce tasks=31645368000
    Map-Reduce Framework
        Map input records=728795619
        Map output records=728795618
        Map output bytes=50859151614
        Map output materialized bytes=10506705085
        Input split bytes=16874
        Combine input records=0
        Spilled Records=1457591236
        Failed Shuffles=0
        Merged Map outputs=0
        GC time elapsed (ms)=150143
        CPU time spent (ms)=14360870
        Physical memory (bytes) snapshot=43327889408
        Virtual memory (bytes) snapshot=108950675456
        Total committed heap usage (bytes)=34940649472
    File Input Format Counters 
        Bytes Read=0

person frankilee    schedule 08.11.2015    source источник


Ответы (2)


Я не уверен в Amazon EMR. Вот несколько моментов, которые следует учитывать при уменьшении карты:

  1. bzip2 работает медленнее, хотя сжимает лучше, чем gzip. Скорость распаковки bzip2 выше, чем скорость сжатия, но все же медленнее, чем у других форматов. Таким образом, на высоком уровне у вас уже есть это по сравнению с программой подсчета слов 40 ГБ, которая работала за десять минут (при условии, что программа на 40 ГБ не имеет сжатия). Следующий вопрос: НО НАСКОЛЬКО МЕДЛЕННЕЕ.

  2. Однако по прошествии часа ваша работа по-прежнему не срабатывает. Пожалуйста, подтвердите это. Так что только тогда, когда работа выполняется успешно, мы можем говорить о производительности. По этой причине давайте подумаем, почему это не удается. Вы получали ошибку памяти. Также из-за ошибки контейнер выходит из строя во время фазы редуктора (так как фаза сопоставления завершена на 100%). В большинстве случаев даже один редуктор не смог бы сработать. Несмотря на то, что 32% могут заставить вас думать, что некоторые редукторы работают, этот% может быть связан с подготовкой работы по очистке перед первым запуском редуктора. Один из способов подтвердить это - посмотреть, есть ли у вас выходной файл редуктора.

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

Ваша версия 1 поможет вам узнать, вызывает ли проблема только конкретный контейнер и позволяет ли задание завершить работу.

person Ramzy    schedule 09.11.2015
comment
Привет, Рамзи, спасибо за ответ! Моя работа MR завершилась неудачно через час, и у меня не было сгенерировано никакого выходного файла редуктора. Я пробовал версию 2 на Amazon EMR, но сообщение об ошибке все равно появляется. Есть ли другие способы решения этой проблемы? Спасибо! - person frankilee; 09.11.2015
comment
Вы были уверены, что настройки памяти обновились. Я имею в виду, что если это так, ошибка может быть обновлена ​​Текущее использование: используется 3,0 ГБ из 3 ГБ физической памяти с последними настройками - person Ramzy; 09.11.2015
comment
Спасибо! Я думаю, что последние настройки не были обновлены путем простого изменения Configuration conf = new Configuration() в коде Java, мне, вероятно, нужно обновить настройки с помощью чего-то вроде AWS Configuration - person frankilee; 09.11.2015
comment
Привет, Рамзи, я изменил эти параметры при создании кластера на Amazon EMR, теперь сообщения об ошибках изменены на Контейнер убит по запросу. Код выхода 137, Контейнер завершился с ненулевым кодом выхода 137, Прервано внешним сигналом, я думаю, что моя работа MR выполняет много вторичной сортировки, поэтому она занимает так много памяти. - person frankilee; 10.11.2015
comment
Привет, по крайней мере, есть прогресс. Можете ли вы посмотреть здесь. Свойство yarn.scheduler.minimum-allocation-mb необходимо обрабатывать в соответствии с вашей рабочей нагрузкой. Стоит попробовать - person Ramzy; 10.11.2015
comment
Наконец, я использовал более крупный кластер EMR, избавился от вторичной сортировки и использовал редукторы правильного размера 0,75 ~ 0,95 (# ofNodes * # ofCPUCores). Чтобы настроить параметры, я загрузил файл JSON при создании MR Job на AWS EMR. Спасибо, Рамзи. - person frankilee; 17.11.2015

Размер вашего входного файла должен заключать количество редукторов. Стандартным является 1 редуктор на 1 ГБ, если вы не сжимаете выходные данные Mapper. Так что в этом случае идеальное число должно быть не менее 38. Попробуйте передать параметр командной строки как -D mapred.reduce.tasks = 40 и посмотрите, есть ли какие-либо изменения.

person Vineet Srivastava    schedule 09.11.2015
comment
Спасибо, Винит. Скажите, пожалуйста, почему идеальное число должно быть 38? Я провел небольшое исследование и нашел этот документ, кажется, что reduce task = p * (узлы * mapred.tasktracker.reduce.tasks.maximum), где p = 0,75 или 0,95, узлы = 3, mapred.tasktracker.reduce.tasks.maximum = количество ядер процессора в каждом узле = 4, поэтому , mapreduce.job.reduces = от 9 до 11 (к сведению: mapred.reduce.tasks устарел. Вместо этого используйте mapreduce.job.reduces) - person frankilee; 10.11.2015
comment
Это аналогичная проблема, которая возникла у меня, и с некоторой ссылкой в ​​Google я настроил свой класс работы для расчета количества редукторов в соответствии с ГБ редуктора Input 1 и преодолел это. - person Vineet Srivastava; 10.11.2015
comment
Привет, Vineet, спасибо за ваш ответ и дайте мне другой подход к решению этой проблемы, я разрешил mapreduce.job.reduces = 40, но ошибка все равно осталась. Я думаю, что моя MR-работа связана с сортировкой, поэтому для этого требуется большой объем памяти. И я нашел еще один хороший документ о сколько редукторов мне следует использовать? - person frankilee; 10.11.2015