gpt4 book ai didi

hadoop - Distcp - 容器运行超出物理内存限制

转载 作者:可可西里 更新时间:2023-11-01 14:43:02 25 4
gpt4 key购买 nike

几天来我一直在与 distcp 作斗争,我发誓我已经用 google 搜索了足够多的东西。这是我的用例:

用例

我在某个位置有一个主文件夹,比如 /hdfs/root,里面有很多子目录(深度不固定)和文件。

数量:200,000 个文件 ~= 30 GO

我只需要为客户端复制一个子集,/hdfs/root 在另一个位置,比如/hdfs/dest该子集由可以随时间更新的绝对路径列表定义。

数量:50,000 个文件 ~= 5 GO

你知道我不能使用简单的 hdfs dfs -cp/hdfs/root/hdfs dest 因为它没有优化,它会占用每个文件,而且它没有 -更新模式。

解决方案概念验证

我最终以两种方式使用 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

Algo 2 甚至没有开始,似乎在源和黑名单之间建立差异对他来说太难了,所以我使用 Algo 1,而且它有效。

OOZIE 工作流程

知道我需要在 Oozie 工作流中安排所有工作流。我已将算法 2 放入 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 不是无限的,所以我不能再进一步了。这是我的假设:

  1. distcp 作业不释放内存(JVM 垃圾收集器?)
  2. Oozie 将所有 distcp 作业的添加视为当前内存使用情况,这是愚蠢的
  3. 这不是正确的方法(我知道,但仍然如此)

此外,关于内存管理还有很多我不了解的地方,它很模糊(yarn、oozie、jvm、mapreduce)。

在谷歌搜索时,我注意到很少有人在谈论真正的 distcp 用例,这篇文章已有 4 天了:https://community.hortonworks.com/articles/71775/managing-hadoop-dr-with-distcp-and-snapshots.html并解释了我无法在我的案例中使用的快照用法。

我也听说过 http://atlas.incubator.apache.org这最终会通过“标记”文件并授予特定用户访问权限来解决我的问题,这样我们就可以避免复制到某个位置。我的管理团队正在研究它,但我们不会让它投入生产。

我很绝望。帮助我。

最佳答案

YARN 容器构建于 Linux“cgroups”之上。这些“cgroups”用于对 CPU 进行软限制,而不是对 RAM...
因此,YARN 使用了一个笨拙的解决方法:它定期检查每个容器使用了多少 RAM,并残忍地杀死任何超过配额的东西。所以你丢失了执行日志,只得到你看到的那条可怕的消息。

在大多数情况下,您正在运行某种 JVM 二进制文件(即 Java/Scala 实用程序或自定义程序),因此您可以通过设置自己的 JVM 配额(尤其是 -Xmx)来摆脱困境,因此你总是保持在 YARN 限制之下。这意味着由于安全裕度而浪费了一些 RAM。但更糟糕的情况是当 JVM 内存不足时完全失败,您可以充分获取执行日志,然后可以开始调整配额——或修复内存泄漏 :-/

那么在您的具体情况下会发生什么?您正在使用 Oozie 启动一个 shell——然后该 shell 启动一个在 JVM 中运行的 hadoop 命令。您必须在嵌入式 JVM 上设置最大堆大小。


长话短说:如果您为运行 shell 的 YARN 容器分配 32GB(通过 oozie.launcher.mapreduce.map.memory.mb),那么您必须确保 shell 中的 Java 命令不会消耗超过 28GB 的​​堆(为了安全起见)。

如果幸运的话,设置一个环境变量就可以了:

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

如果你不走运,你将不得不打开 hadoop-env.sh 的整个困惑,将不同的 env 变量与不同的设置混合(由明显讨厌你的人设置,在初始化脚本中你甚至不知道)由 JVM 使用复杂的优先规则解释。玩得开心。你可以看看 that very old post有关挖掘位置的提示。

关于hadoop - Distcp - 容器运行超出物理内存限制,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41226242/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com