我在运行类似字数的mapreduce程序时遇到奇怪的错误。我有一个 Hadoop集群，有 20 个从属设备，每个从站有 4 GB RAM。我将地图任务配置为具有 300MB 的堆，而我的缩减任务槽获得 1GB。我有 2 个地图槽，每个节点有 1 个减少槽。一切顺利，直到第一轮地图任务完成。然后进展保持在100%。我想然后复制阶段正在发生。每个地图任务都会生成如下内容：
Map output bytes 4,164,335,564
Map output materialized bytes 608,800,675
(我正在使用SnappyCodec进行压缩(
停滞大约一个小时后，减少任务会崩溃，但以下情况除外：
Error: java.lang.OutOfMemoryError: Java heap space at
org.apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.shuffleInMemory(ReduceTask.java:1703) at
org.apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.getMapOutput(ReduceTask.java:1563) at
org.apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.copyOutput(ReduceTask.java:1401) at
org.apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.run(ReduceTask.java:1333
我在谷歌上搜索并找到了这个链接，但我真的不知道该怎么做：哈多普公共链接
我不明白为什么 hadoop 如果能够执行 terasort 基准测试，它会在复制和合并时遇到任何问题。不可能所有映射输出都应该适合化简器线程的 RAM。这到底是怎么回事呢？
在上面提供的链接中，他们讨论了如何调整以下参数：
mapreduce.reduce.shuffle.input.buffer.percent = 0.7
mapreduce.reduce.shuffle.memory.limit.percent = 0.25
mapreduce.reduce.shuffle.parallelcopies = 5
他们声称参数的乘积为>1 的事实允许堆大小错误。编辑：请注意，5 * 1.25 * 0.7仍然是<1，因此请关注我的第二个解决方案帖子！在重新开始这个密集的模拟之前，我很高兴听到有人对我面临的问题的看法，因为它已经困扰了将近一周了。我似乎也不完全了解这个复制阶段发生了什么，我希望磁盘上的合并排序不需要太多的堆大小？
提前非常感谢任何有用的评论和答案！
线索是我的reduce任务的堆几乎完全需要用于reduce阶段。但是洗牌阶段正在争夺相同的堆空间，出现的冲突导致我的工作崩溃。我认为这解释了为什么如果我降低shuffle.input.buffer.percent，作业不再崩溃。
你引用mapred.job.shuffle.input.buffer.percent参数显然是Hadoop 2之前的参数。 我可以在 mapred-default 中找到该参数.xml根据 1.04 文档，但它的名称已更改为 mapreduce.reduce.shuffle.input.buffer.percent 每个 2.2.0 文档。
根据文档，此参数的描述是：
在随机播放期间从最大堆大小到存储映射输出要分配的内存百分比。
要全面了解排序和随机播放，请参阅Hadoop权威指南的第6.4章。 这本书提供了参数mapred.job.shuffle.input.buffer.percent的替代定义：
在随机播放的复制阶段分配给映射输出缓冲区的总堆大小的比例。
由于您观察到将mapred.job.shuffle.input.buffer.percent的值从默认值0.7减小到0.2解决了您的问题，因此可以肯定地说，您也可以通过增加化简器的堆大小的值来解决您的问题。
shuffle.input.buffer.percent更改为 0.2，它也对我不起作用，并且出现相同的错误。
在单节点群集上进行命中和试用后，我发现/目录中需要有足够的空间，因为进程会在溢出时使用该空间。
溢出目录也需要更改。
相关错误 - https://issues.apache.org/jira/browse/MAPREDUCE-6724
可能导致负数组大小异常，如果计算的 maxSingleShuffleLimit> MAX_INT