当我检查hadoopgui时,我发现一些reduce任务已经达到66.66%,并且它们在那里停留了很长时间。当我检查计数器时,我发现输入记录的数量显示为零。
经过很长一段时间,他们得到了他们的输入记录,开始处理它们。有些在中显示0条输入记录的时间甚至更长,并且被600毫秒内任务尝试报告状态失败而终止。
但是有些还原程序会立即在其计数器中显示输入记录,并立即开始处理它们。
我不知道,为什么在获取一些减速机的输入记录时会有这么多的延迟。这只会发生在这个程序中,而不会发生在其他程序中。
在这个mapreduce作业中,我在reduce的reduce方法之前的configure方法中,从分布式缓存中读取了大量数据。这就是原因吗?我不确定。
1条答案
按热度按时间wvt8vs2t1#
是的,我相信分布式缓存的读取是您延迟的原因。但如果你坚持下去就不会有什么不同了
configure()
在考试之前还是之后reduce()
最终configure()
如果您看到run()
减速器的外观如下(新api):如你所见
setup()
在前面调用reduce()
,类似地,在旧的api中,除非configure()
完成实际的reduce任务不会启动(这说明您没有看到任何显示的输入记录计数)。至于百分比:
66%
,您可以看到reduce阶段实际上包含以下子部分:复制
分类
减少
所以,因为你的前两个步骤已经完成,第三个步骤已经开始,但正在等待
configure()
要完成(要读取的分布式缓存),减少百分比为66%。