Distcp - 容器 运行 超出了物理内存限制
Distcp - Container is running beyond physical memory limits
几天来我一直在为 distcp 苦苦挣扎，我发誓我已经用 google 搜索够了。这是我的用例：
用例
我在某个位置有一个主文件夹，比如/hdfs/root，里面有很多子目录（深度不固定）和文件。
数量：200,000 个文件 ~= 30 GO
我只需要为客户复制一个子集，/hdfs/root 在另一个位置，比如 /hdfs/dest
该子集由可以随时间更新的绝对路径列表定义。
数量：50,000 个文件 ~= 5 GO
你知道我不能使用简单的 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
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 不是无限的，所以我不能再进一步了。这是我的假设：
- distcp 作业不释放内存（JVM 垃圾收集器？）
- Oozie把所有distcp job的加法看成是当前内存使用量，傻
- 这不是正确的方法（我知道，但仍然如此）
另外，关于内存管理，我有很多地方没看懂，一头雾水（yarn, oozie, jvm, mapreduce）。
在谷歌搜索时，我注意到很少有人在谈论真正的 distcp 用例，这个 post 是 4 天前的：https://community.hortonworks.com/articles/71775/managing-hadoop-dr-with-distcp-and-snapshots.html 并解释了快照的用法，我不能在我的案例.
我还听说 http://atlas.incubator.apache.org 最终会通过 "tagging" 文件解决我的问题，并授予特定用户访问权限，这样我们就可以避免复制到特定位置。我的管理团队正在努力，但我们不会将其投入生产。
我很绝望。帮帮我。
YARN 容器构建于 Linux "cgroups" 之上。这些 "cgroups" 用于对 CPU 设置软限制，但不对 RAM...
因此，YARN 使用了一个笨拙的解决方法：它定期检查每个容器使用了多少 RAM，并且 杀死 任何超过配额的东西。所以你丢失了执行日志，只得到你看到的那条可怕的消息。
在大多数情况下，您是 运行 某种 JVM 二进制文件（即 Java/Scala 实用程序或自定义程序），因此您可以通过设置自己的 JVM 配额（尤其是 -Xmx) 这样您就可以始终保持在 YARN 限制之下。这意味着由于安全裕度而浪费了一些 RAM。但更糟糕的情况是当 JVM 内存不足时完全失败，你会得到扩展 中的执行日志 并且可以开始调整配额 - 或者修复你的内存泄漏 :-/
那么在你的具体情况下会发生什么？您正在使用 Oozie 启动一个 shell —— 然后 shell 启动一个 hadoop 命令，该命令在 JVM 中运行。您必须在 嵌入式 JVM 上设置最大堆大小。
长话短说：如果您将 32GB 分配给运行 shell 的 YARN 容器（通过 oozie.launcher.mapreduce.map.memory.mb），那么您必须确保 shell 中的 Java 命令不会消耗超过 28GB 的堆（为了安全起见）。
如果幸运的话，设置一个环境变量就可以了：
export HADOOP_OPTS=-Xmx28G
hadoop distcp ...........
如果你不走运，你将不得不解开 hadoop-env.sh 混合不同环境变量和不同设置的整个混乱（由明显讨厌你的人设置，在你甚至不知道的初始化脚本中) 由 JVM 使用复杂的优先规则解释。玩得开心。您可以查看 that very old post 以获得有关挖掘位置的提示。
几天来我一直在为 distcp 苦苦挣扎，我发誓我已经用 google 搜索够了。这是我的用例：
用例
我在某个位置有一个主文件夹，比如/hdfs/root，里面有很多子目录（深度不固定）和文件。
数量：200,000 个文件 ~= 30 GO
我只需要为客户复制一个子集，/hdfs/root 在另一个位置，比如 /hdfs/dest 该子集由可以随时间更新的绝对路径列表定义。
数量：50,000 个文件 ~= 5 GO
你知道我不能使用简单的 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
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 不是无限的，所以我不能再进一步了。这是我的假设：
- distcp 作业不释放内存（JVM 垃圾收集器？）
- Oozie把所有distcp job的加法看成是当前内存使用量，傻
- 这不是正确的方法（我知道，但仍然如此）
另外，关于内存管理，我有很多地方没看懂，一头雾水（yarn, oozie, jvm, mapreduce）。
在谷歌搜索时，我注意到很少有人在谈论真正的 distcp 用例，这个 post 是 4 天前的：https://community.hortonworks.com/articles/71775/managing-hadoop-dr-with-distcp-and-snapshots.html 并解释了快照的用法，我不能在我的案例.
我还听说 http://atlas.incubator.apache.org 最终会通过 "tagging" 文件解决我的问题，并授予特定用户访问权限，这样我们就可以避免复制到特定位置。我的管理团队正在努力，但我们不会将其投入生产。
我很绝望。帮帮我。
YARN 容器构建于 Linux "cgroups" 之上。这些 "cgroups" 用于对 CPU 设置软限制，但不对 RAM...
因此，YARN 使用了一个笨拙的解决方法：它定期检查每个容器使用了多少 RAM，并且 杀死 任何超过配额的东西。所以你丢失了执行日志，只得到你看到的那条可怕的消息。
在大多数情况下，您是 运行 某种 JVM 二进制文件（即 Java/Scala 实用程序或自定义程序），因此您可以通过设置自己的 JVM 配额（尤其是 -Xmx) 这样您就可以始终保持在 YARN 限制之下。这意味着由于安全裕度而浪费了一些 RAM。但更糟糕的情况是当 JVM 内存不足时完全失败，你会得到扩展 中的执行日志 并且可以开始调整配额 - 或者修复你的内存泄漏 :-/
那么在你的具体情况下会发生什么？您正在使用 Oozie 启动一个 shell —— 然后 shell 启动一个 hadoop 命令，该命令在 JVM 中运行。您必须在 嵌入式 JVM 上设置最大堆大小。
长话短说：如果您将 32GB 分配给运行 shell 的 YARN 容器（通过
oozie.launcher.mapreduce.map.memory.mb），那么您必须确保 shell 中的 Java 命令不会消耗超过 28GB 的堆（为了安全起见）。
如果幸运的话，设置一个环境变量就可以了：
export HADOOP_OPTS=-Xmx28G
hadoop distcp ...........
如果你不走运，你将不得不解开 hadoop-env.sh 混合不同环境变量和不同设置的整个混乱（由明显讨厌你的人设置，在你甚至不知道的初始化脚本中) 由 JVM 使用复杂的优先规则解释。玩得开心。您可以查看 that very old post 以获得有关挖掘位置的提示。