容器在物理内存之外运行更大的文件答案

【问题标题】：Container is running beyond physical memory for larger files容器在物理内存之外运行更大的文件
【发布时间】：2015-01-26 01:58:17
【问题描述】：

我有一个小型 hadoop (2.5.1) 集群，其中有以下配置

（关于内存限制） mapred-site.xml：

    <property>
            <name>mapreduce.map.memory.mb</name>
            <value>3072</value>
    </property>
    <property>
            <name>mapreduce.reduce.memory.mb</name>
            <value>2048</value>
    </property>
    <property>
            <name>mapreduce.map.java.opts</name>
            <value>-Xmx2450m</value>
    </property>
    <property>
            <name>mapreduce.reduce.java.opts</name>
            <value>-Xmx1630m</value>
    </property>

yarn-site.xml：

      <property>
            <name>yarn.nodemanager.resource.memory-mb</name>
            <value>13312</value>
    </property>

还有一个使用python（没有reducer）的地图流任务，我只是从文件中读取行并选择要打印的特定字段（我将其中一个字段作为键，其余的作为一个大字符串）。

每一行都包含一个相当大的数组，因此默认的 hadoop 配置更改为上面的配置（只是为了确保每条记录都适合映射器，这样我就可以测试我的代码而不必担心内存）。虽然每行/记录都小于块大小（我保留了默认值）。

我的问题是，当我在原始文件的 7gb 样本上测试我的代码时，一切都运行得很好，但是当我在原始文件 (~100GB) 上尝试它时，大约 50% 的映射阶段我得到错误“容器在物理内存之外运行更大的文件”，它报告它已经超过了 3GB 的限制。

为什么映射器需要更多内存来存储更大的文件？计算不应该逐条记录吗？如果块大小小于（很多）可用内存，映射器如何最终使用超过 3GB？

我觉得这个问题有点令人困惑。

【问题讨论】：

标签： python hadoop memory-management mapreduce hadoop-streaming

【解决方案1】：

如果我正确地解释了您的场景，并不是单个映射器正在破坏您的内存，而是可能会并行生成更多的映射器，因为有更多的输入块 - 这就是很多Hadoop的并行性来自于。内存错误可能是由于太多映射器试图在每个节点同时运行。如果您有一个小型集群，您可能需要为较大的输入集保持较低的映射器/节点比率。

此 SO 问题/答案包含有关影响映射器计数的更多详细信息。 Setting the number of map tasks and reduce tasks

【讨论】：

好的，我可以通过增加输入大小来减少映射器的数量（因为根据我的经验，设置数字没有任何作用）。但是我应该假设每个映射器需要多少内存？例如，在我的配置中，地图的合适输入大小是多少？
每个映射器的内存使用情况在很大程度上取决于它在做什么——例如，在映射器的输出发出之前必须构建的中间对象的数量和大小。如果没有实质性的方法来优化映射器的实现，可能还有其他选择，比如向集群添加更多节点（将相同数量的映射分布在更多节点上），或者增加块大小（只要你的内存消耗不是t 与块大小成正比）。
这并不能解释为什么我在同一文件的较大版本中出现错误，但在样本中却没有。此外，如果我增加块大小会减少拆分次数，但它与增加每个映射器的输入大小具有相同的效果。我尝试同时增加块大小和输入大小，但这会使映射器在较大文件上失败得更快（因为它达到了我设置的内存限制）。我认为原始答案更接近于解决方案，但我仍然不明白块大小与每个映射需要多少内存之间的关系。
我的理解是，更大的输入文件意味着输入集中有更多的块（对于固定的块大小），这意味着会产生更多的映射器。