我怀疑这可能是AWS的内部问题，但由于我目前没有高级AWS支持(更新:已注册以获得AWS支持，所以希望在此处发布)，希望我能从他们那里得到答案) 。
我有一个周期性的EMR工作，最近从使用cc2.8xlarge服务器切换到了c3.8xlarge服务器。在使用新配置进行的第一次运行中，我的一个通常需要2-3分钟的map-reduce作业被卡在上，花费了9个小时以上，将数据从映射器复制到唯一的reducer。我在9.5个小时后取消了工作，尝试在新的EMR群集上开始工作，并且在第一个小时就看到了相同的行为，因此再次取消了工作。当我将工作切换回使用cc2.8xlarge服务器时，该工作在2-3分钟内完成。
我检查了AWS的Health Dashboard，但未显示任何错误。在所有帐户上，c3.8xlarge服务器应与cc2.8xlarge相同或更快(更多CPU，使用SSD等)。看起来所有群集都在us-east-1a上。
有没有人遇到类似的问题？关于如何进一步调试的任何想法？
最佳答案
c3.8large和cc2.8xlarge之间有2个可能引起问题的差异:
如果使用Hadoop 2.0，请检查here以进行验证；如果使用Hadoop 1.0，请检查here以进行验证
如果您使用Hadoop 1.0(如提供的链接所示)，则对于c3.8xlarge实例，映射器和化简器的数量要多得多(默认情况下)。这意味着为每个映射分配的内存更少，从而 reduce task (因为两种实例类型或多或少都具有相同的内存)
描述问题的方式听起来像是您的作业内存不足，因此开始使用磁盘。这可以从我上面列出的第二个问题中得到解释。
@Dolan Antenucci:*现在关于m1.xlarge与m3.xlarge问题，我们在某些 I / O受限的 emr作业中也遇到了相同的问题。我们已经得出结论，其背后的原因是m3.xlarge实例的磁盘空间比m1.xlarge实例的磁盘空间小得多(少了1.6 TB)。因此，在我们的案例中，我们遇到的错误是某种“空间不足错误”。
这对于检查您是否也遇到相同类型的错误可能很有用。