distcp-container的运行超出了物理内存限制

9bfwbjaz  于 2021-05-29  发布在  Hadoop
关注(0)|答案(1)|浏览(374)

我已经和distcp打了好几天架了,我发誓我已经用google搜索够了。以下是我的用例:

用例

我在某个位置有一个主文件夹,比如/hdfs/root,有很多子目录(深度不是固定的)和文件。
卷:200000个文件~=30个
我只需要为一个客户机复制一个子集,/hdfs/root在另一个位置,比如说/hdfs/dest这个子集是由一个绝对路径列表定义的,可以随时间更新。
卷:50000个文件~=5个
你知道我不能用一个简单的 hdfs dfs -cp /hdfs/root /hdfs dest 因为它没有被优化,它会占用所有的文件,而且它没有一个-更新模式。

解决方案poc

我最终以两种方式使用hadoop distcp:

Algo 1 (simplified):

# I start up to N distcp jobs in parallel for each subdir, with N=MAX_PROC (~30)

foreach subdir in mylist: 
    # mylist = /hdfs/root/dirX/file1 /hdfs/root/dirX/file2 ...
    mylist = buildList(subdirs)
    hadoop distcp -i -pct -update mylist /hdfs/dest/subdir &

Algo 2

# I start one distcp that has a blacklist

blacklist = buildBlackList()
hadoop distcp -numListstatusThread 10 -filters blacklist -pct -update /hdfs/root /hdfs/dest

algo2甚至没有启动,似乎在源代码和黑名单之间建立一个差异对他来说太难了,所以我使用algo1,它工作了。

oozie工作流

我知道我需要在oozie工作流中安排所有工作流。我已经将algo2放在shell操作中,因为我有很多distcp命令,并且在oozie中我不掌握递归或循环。
一旦启动,一段时间后,我得到以下错误:容器运行超出物理内存限制。当前使用情况:使用了17.2 gb的16 gb物理内存
好吧,我要增加更多的记忆:

<configuration>
    <property>
        <name>oozie.launcher.mapreduce.map.memory.mb</name>
        <value>32768</value>
    </property>
    <property>
        <name>oozie.launcher.mapreduce.map.java.opts</name>
        <value>-Xmx512m</value>
    </property>
</configuration>

我仍然得到:容器运行超出了物理内存限制。当前使用情况:使用了32.8 gb的32 gb物理内存,但该作业的寿命是前一个作业的两倍。
我集群上的ram不是无限的,所以我不能再进一步了。以下是我的假设:
distcp作业不会释放内存(jvm垃圾收集器?)
oozie将添加所有distcp作业视为当前内存使用量,这是愚蠢的
这不是正确的方法(我知道,但仍然)
另外,关于内存管理还有很多我不了解的地方,它非常模糊(yarn、oozie、jvm、mapreduce)。
在google上,我注意到很少有人谈论真正的distcp用例,这篇文章已经发布了4天了:https://community.hortonworks.com/articles/71775/managing-hadoop-dr-with-distcp-and-snapshots.html 并解释了快照的用法,在我的案例中无法使用。
我也听说过http://atlas.incubator.apache.org that 最终将通过“标记”文件并授予特定用户访问权限来解决我的问题,这样我们就可以避免复制到特定位置。我的管理团队正在努力,但我们不会让它的生产知道。
我很绝望。帮助我。

jm81lzqq

jm81lzqq1#

Yarn容器构建在linux“cgroups”之上。这些“cgroup”用于对cpu进行软限制,而不是对ram进行软限制。。。
因此,yarn使用了一种笨拙的解决方法:它定期检查每个容器使用了多少ram,并残忍地杀死超过配额的任何东西。因此,您丢失了执行日志,只得到您看到的可怕消息。
在大多数情况下,您运行的是某种jvm二进制文件(即java/scala实用程序或自定义程序),因此您可以通过设置自己的jvm配额(尤其是 -Xmx )所以你总是在Yarn的限制下。这意味着由于安全裕度而浪费了一些内存。但更糟糕的情况是jvm在内存不足时完全失败,您可以在extenso中获得执行日志并开始调整配额,或者修复内存泄漏 :-/ 那么在你的具体案例中会发生什么呢?您正在使用oozie启动一个shell--然后shell启动一个 hadoop 命令,该命令在jvm中运行。必须在嵌入的jvm上设置最大堆大小。
长话短说:如果您将32gb分配给运行shell的yarn容器(通过 oozie.launcher.mapreduce.map.memory.mb )然后必须确保shell中的java命令不会消耗超过28gb的堆(为了安全起见)。
如果幸运的话,设置一个env变量就可以了:

export HADOOP_OPTS=-Xmx28G
hadoop distcp ...........

如果你运气不好,你就得把这堆乱七八糟的东西拆开 hadoop-env.sh 混合不同的env变量和不同的设置(由明显讨厌你的人设置,在你甚至不知道的init脚本中),由jvm使用复杂的优先规则来解释。玩得高兴。你可以看看那篇很老的帖子,想知道该去哪里挖掘。

相关问题