org.apache.hadoop.mapred.YarnChild: ошибка при запуске дочернего элемента: java.lang.OutOfMemoryError: пространство кучи Java

У меня есть быстро сжатый файл размером 90 МБ, который я пытаюсь использовать в качестве входных данных для Hadoop 2.2.0 на AMI 3.0.4 в AWS EMR.

Сразу же при попытке прочитать файл мой считыватель записей получает следующее исключение:

2014-05-06 14:25:34,210 FATAL [main] org.apache.hadoop.mapred.YarnChild: Error running child : java.lang.OutOfMemoryError: Java heap space
at org.apache.hadoop.io.compress.BlockDecompressorStream.getCompressedData(BlockDecompressorStream.java:123)
at org.apache.hadoop.io.compress.BlockDecompressorStream.decompress(BlockDecompressorStream.java:98)
at org.apache.hadoop.io.compress.DecompressorStream.read(DecompressorStream.java:85)
at java.io.InputStream.read(InputStream.java:101)
at org.apache.hadoop.util.LineReader.readDefaultLine(LineReader.java:211)
at org.apache.hadoop.util.LineReader.readLine(LineReader.java:174)
at org.apache.hadoop.util.LineReader.readLine(LineReader.java:365)
...

Я использую m1.xlarge в AWS, используя память по умолчанию и io.sort.mb. Если мы распаковываем файл и используем его в качестве входных данных, все идет нормально. Проблема в том, что у нас очень много сжатых файлов, и мы не хотим распаковывать все подряд.

Я не уверен, что нам не хватает параметра конфигурации или какой-то проводки в нашем коде. Не знаю, как действовать.


hadoop snappy emr
person Sarah Haskins    schedule 06.05.2014    source источник
comment
Файл представляет собой файл .sz и был создан с помощью snzip. У меня есть собственное определение кода для файлов .sz (io.compression.codecs).   -  person Sarah Haskins    schedule 06.05.2014
comment
Если я изменю расширение файла с .sz на .unknown, я смогу прочитать весь файл, и задание карты завершится успешно. Я считаю, что этот вопрос связан с: stackoverflow.com/questions/15558315/   -  person Sarah Haskins    schedule 07.05.2014

Ответы (1)


arrow_upward
2
arrow_downward

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

Я не знаю о спецификациях экземпляра m1.large в EMR, однако вот некоторые вещи, которые вы можно попытаться предотвратить эту ошибку.

Обычно ошибка при запуске дочернего элемента означает, что дочерний элемент, созданный пряжей, не может найти достаточно места в куче для продолжения своей работы MR.

> Возможные варианты:

1) Увеличьте размер mapred.java.child.opts. Это размер по умолчанию, который дочерний элемент получает как отдельный процесс JVM. По умолчанию это 200 МБ, что мало для любого разумного анализа данных. Измените параметры -XmxNu(максимальный размер кучи N в единицах u) и -XmsNu (начальный размер кучи N в единицах u). Попробуйте использовать 1Gb, т.е. -Xmx1g, и посмотрите на эффект, и если это удастся, уменьшите размер

2) установите mapred.child.ulimit в 1,5 или 2 раза больше максимального размера кучи, как было установлено ранее. Он устанавливает объем виртуальной памяти для процесса.

3) уменьшите mapred.tasktracker.map.tasks.maximum и mapred.tasktracker.reduce.tasks.maximum, чтобы установить максимальное количество параллельных картографов и редукторов, работающих одновременно.

4) io.sort.mb - который вы уже попробовал. попробуйте 0.25*mapred.child.java.opts < io.sort.mb < 0.5*mapred.child.java.opts .

И, наконец, это метод проб и ошибок, так что попробуйте и посмотрите, какой из них подходит.

person Chandra kant    schedule 06.05.2014
comment
Я установил mapreduce.map.java.opts=-Xmx2g, что является максимально доступным, но все же получил то же исключение. (Обратите внимание, что я на 2.2.0, поэтому mapreduce.map.java.opts является новым эквивалентом mapred.java.child.opts.) Затем я добавил к этому параметру mapred.tasktracker.map.tasks.maximum=1 и получил опять та же ошибка. Наконец, я добавил mapreduce.task.io.sort.mb=819 и получил ту же ошибку. Я не устанавливал ulimit, потому что в моем выводе было сообщение Переменная mapred.child.ulimit больше не используется. - person Sarah Haskins; 06.05.2014
comment
@SarahHaskins Итак, проблема была в том, как EMR обрабатывает быстро сжатые данные. В любом случае, полезно знать... и все параметры, которые я написал, были протестированы на hadoop-1.2.x. - person Chandra kant; 07.05.2014