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

Question

我已经为 distcp 苦苦挣扎了好几天，我发誓我已经用谷歌搜索了足够多的东西。这是我的用例：

用例

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

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

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

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

您知道我不能使用简单的hdfs dfs -cp /hdfs/root /hdfs dest，因为它没有经过优化，它会占用每个文件，并且它没有-update 模式。

解决方案概念

我最终以两种方式使用 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 最终会通过“标记”文件并授予特定用户访问权限来解决我的问题，这样我们就可以避免复制到某个位置。我的管理团队正在处理它，但我们不会将它投入生产。

我很绝望。帮帮我。

Answer 1

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

在大多数情况下，您正在运行某种 JVM 二进制文件（即 Java/Scala 实用程序或自定义程序），因此您可以通过设置自己的 JVM 配额（尤其是-Xmx）来摆脱困境，这样您就可以始终保持在纱线限制。这意味着由于安全裕度而浪费了一些 RAM。但更糟糕的情况是 JVM 在内存不足时彻底失败，您可以extenso 获得执行日志，然后可以开始调整配额——或修复内存泄漏:-/ p>

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

---

长话短说：如果您为运行 shell 的 YARN 容器分配 32GB（通过oozie.launcher.mapreduce.map.memory.mb），那么您必须确保 shell 内的 Java 命令不消耗超过 28GB 的​​堆（以保持安全边）。

如果幸运的话，设置一个 env 变量就可以解决问题：

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

如果你不走运，你将不得不解开hadoop-env.sh 混合不同环境变量和不同设置的整个混乱（由明显讨厌你的人设置，在你甚至不知道的初始化脚本中设置）以进行解释JVM 使用复杂的优先级规则。玩得开心。您可以查看that very old post 以获取有关在哪里挖掘的提示。