2014-11-26 3 views
0

Я перемещался с Hadoop 1 до Hadoop 2 YARN. Исходный код был перекомпилирован с использованием баннеров MRV2 и не имел проблемы с совместимостью. Когда я пытался запустить работу под YARN, карта работала нормально и ушла на 100%, но сокращение было застряло на ~ 6,7%. Нет проблем с производительностью. На самом деле, я проверил использование ЦП, оказалось, что когда был застрял сокращение, похоже, что никаких вычислений не происходит, потому что CPU в основном на 100% бездействует. Работа может успешно выполняться на Hadoop 1.2.1.Hadoop YARN редуктор/перемешивание застрял

Я проверил сообщения журнала с помощью диспетчера ресурсов и выяснил, что, поскольку карта завершена, больше контейнера не было выделено, поэтому на любом контейнере нет никакого сокращения. Что вызвало эту ситуацию?

Мне интересно, связано ли это с настройкой свойства yarn.nodemanager.aux-services. Следуя официальному руководству (http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/SingleCluster.html), это свойство должно быть установлено в mapreduce_shuffle, что указывает на то, что MR по-прежнему будет использовать метод по умолчанию shuffle вместо других плагинов в случайном порядке (http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/PluggableShuffleAndPluggableSort.html). Я старался не устанавливать это свойство, но Hadoop не разрешил мне.

Вот журнал журналов userlogs/applicationforlder/containerfolder/syslog, когда он достигнет 7% от уменьшения. После этого журнал больше не обновлялся, а также остановился.

2014-11-26 09:01:04,104 INFO [fetcher#1] org.apache.hadoop.mapreduce.task.reduce.Fetcher: fetcher#1 about to shuffle output of map attempt_1416988910568_0001_m_002988_0 decomp: 129587 len: 129591 to MEMORY 
2014-11-26 09:01:04,104 INFO [fetcher#1] org.apache.hadoop.mapreduce.task.reduce.InMemoryMapOutput: Read 129587 bytes from map-output for attempt_1416988910568_0001_m_002988_0 
2014-11-26 09:01:04,104 INFO [fetcher#1] org.apache.hadoop.mapreduce.task.reduce.MergeManagerImpl: closeInMemoryFile -> map-output of size: 129587, inMemoryMapOutputs.size() -> 2993, commitMemory -> 342319024, usedMemory ->342448611 
2014-11-26 09:01:04,105 INFO [fetcher#1] org.apache.hadoop.mapreduce.task.reduce.Fetcher: fetcher#1 about to shuffle output of map attempt_1416988910568_0001_m_002989_0 decomp: 128525 len: 128529 to MEMORY 
2014-11-26 09:01:04,105 INFO [fetcher#1] org.apache.hadoop.mapreduce.task.reduce.InMemoryMapOutput: Read 128525 bytes from map-output for attempt_1416988910568_0001_m_002989_0 
2014-11-26 09:01:04,105 INFO [fetcher#1] org.apache.hadoop.mapreduce.task.reduce.MergeManagerImpl: closeInMemoryFile -> map-output of size: 128525, inMemoryMapOutputs.size() -> 2994, commitMemory -> 342448611, usedMemory ->342577136 
2014-11-26 09:01:04,105 INFO [fetcher#1] org.apache.hadoop.mapreduce.task.reduce.ShuffleSchedulerImpl: datanode03:13562 freed by fetcher#1 in 13ms 

Было ли это распространенной проблемой при переходе с Hadoop 1 на 2? Была ли стратегия перехода map-shuffle-sort-reduce изменена в Hadoop 2? Что вызвало эту проблему? Спасибо. Любые комментарии помогут!

Основные установки среды:

  • Hadoop версия: 2.5.2
  • 6-узел кластера с 8-ядерный процессор, 15 Гб памяти на каждом узле

Связанные свойства настройки:

  • yarn.scheduler.maximum-allocation-mb: 14336
  • yarn.scheduler.minimum-распределение-МБ: 2500
  • yarn.nodemanager.resource.memory-MB: 14336
  • yarn.nodemanager.aux-услуги: mapreduce_shuffle
  • mapreduce.task.io.sort.factor : 100
  • mapreduce.task.io.sort.mb: 1024
+0

Каковы настройки, заданные вашей работой? Каковы значения для mapreduce.map.memory.mb и mapreduce.reduce.memory.mb? Каков результат применения драйвера, он просто застрял на 6,7%? – 0x0FFF

+0

mapreduce.map.memory.mb и mapreduce.reduce.memory.mb не установлены, поэтому я думаю, что это означает отсутствие ограничения на карту/сокращение памяти. он застрял на ~ 7%. Я обновил вопрос, чтобы добавить вывод из userlogs/container */syslog. Из журнала я узнал, что сокращение просто прекратило работу, когда оно достигло времени снижения на 7%. –

ответ

0

Наконец решил проблему после того, как прибегая к помощи вокруг и узнал, что я отвечал на этот вопрос три месяца назад уже.

Это из-за перекоса данных.

Смежные вопросы