我有一个90mb的snappy压缩文件，我正试图用它作为aws emr中ami3.0.4上hadoop2.2.0的输入。
尝试读取文件后，我的记录读取器立即出现以下异常：
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)
...我在aws中的m1.xlarge上运行，使用默认内存和io.sort.mb。如果我们解压文件并用它作为输入，一切都会好起来的。问题是我们有大量的压缩文件，不想到处去解压所有的东西。
我不确定我们的代码中是否缺少配置设置或连线。不知道如何进行。
1条答案
按热度按时间ncgqoxb01#
根据您提供的日志，似乎解压块的大小大于可用堆的大小。
我不知道emr上的m1.large示例规范，但是这里有一些可以避免这个错误的方法。
通常，运行child时出错意味着生成的子进程找不到足够的堆空间来继续其mr作业。
要尝试的选项：
1） 增加
mapred.java.child.opts大小。它是子进程作为其单独的jvm进程获得的默认大小。默认情况下，它的大小为200mb，对于任何合理的数据分析来说都很小。更改参数-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设置一次运行的平行Map器和减速器的最大数量。4)
io.sort.mb-你已经试过了。试试看0.25*mapred.child.java.opts < io.sort.mb < 0.5*mapred.child.java.opts.最后，这是一个试错法，所以试着看看哪一个坚持。