hadoop - 为什么使用 c3.8xlarge 服务器的 AWS EMR 作业与使用 cc2.8xlarge 服务器的相同作业相比会严重滞后？

Question

我怀疑这可能是 AWS 端的内部问题，但我想在这里发帖，因为我 目前没有高级 AWS 支持 (更新: 已签名申请 AWS 支持，希望我能从他们那里得到答案)。

我有一份经常性的 EMR 工作，最近我从使用 cc2.8xlarge 服务器切换到 c3.8xlarge 服务器。在我第一次使用新配置运行时，我的一个通常需要 2-3 分钟的 map-reduce 作业被卡住了，花费了超过 9 个小时将数据从映射器复制到唯一的 reducer。我在 9.5 小时后终止了作业，重新尝试在新的 EMR 集群上启 Action 业，我在第一个小时内看到了相同的行为，因此再次终止了它。当我将工作切换回使用 cc2.8xlarge 服务器时，工作在 2-3 分钟内完成。

我检查了 AWS 的 Health Dashboard，但未显示任何错误。 c3.8xlarge 服务器在所有帐户上都应该与 cc2.8xlarge 相同或更快(更多 CPU、使用 SSD 等)。看起来所有集群都在 us-east-1a 上。

有人遇到过类似的问题吗？关于如何进一步调试的任何想法？

Answer 1

c3.8large 和 cc2.8xlarge 之间有 2 个差异可能会导致问题:

1. c3.8xlarge 机器的磁盘空间要少得多(少 2.8 TB)。不过我相信这似乎不是您的问题。
2. c3.8xlarge 为 mapreduce 任务分配的内存较少(默认配置)。

检查 here用于验证您是否使用 Hadoop 2.0 或 here如果你使用 Hadoop 1.0

如果您使用 Hadoop 1.0，如您在所提供的链接中所见，c3.8xlarge 实例的映射器和缩减器的数量(默认情况下)要高得多。这意味着为每个 map 和 reduce 任务分配的内存更少(因为两种实例类型或多或少具有相同的内存)

您描述问题的方式听起来像是您的作业内存不足，因此开始改用磁盘。这可以从我上面列出的第二个问题来解释。

@Dolan Antenucci:*现在关于 m1.xlarge 与 m3.xlarge 的问题，我们在一些I/O-bounded emr 作业中也面临同样的问题。我们得出的结论是，这背后的原因是 m3.xlarge 实例的磁盘空间比 m1.xlarge 实例小得多(少 1.6 TB)。所以在我们的例子中，我们得到的错误是某种“空间不足错误”。检查您是否也遇到相同类型的错误可能对您很有用。