使用EMR集群时Nutch作业第二轮抓取阶段无报错失败原因咨询

我之前维护Nutch集群时碰到过一模一样的无声停摆情况，这种没报错的问题排查起来最费神，给你整理几个高频触发的原因：

• 待抓取URL队列耗尽：第一轮抓取后，新发现的URL要么为空，要么被URL过滤规则（比如regex-urlfilter.txt）全部拦截了。你可以用命令nutch readdb <你的crawldb路径> -stats查看CrawlDB的统计数据，重点看db_unfetched状态的条目数，如果是0，那作业自然就没有后续任务可执行了。
• 集群资源临界耗尽：EMR的YARN节点内存或CPU在第二轮抓取时刚好触达临界值，导致Nutch的进程被系统静默终止，却没触发常见的OOM（内存溢出）报错。你可以去EMR控制台的YARN日志里翻NodeManager的记录，或者查看Nutch的nutch.log，找找有没有类似“process terminated”的模糊提示。另外可以尝试调高Nutch的JVM资源参数，比如mapreduce.map.memory.mb和mapreduce.reduce.memory.mb。
• CrawlDB/LinkDB隐性损坏：第一轮抓取完成后，CrawlDB或LinkDB在写入时出现了隐性损坏，导致第二轮读取数据时无法正常加载。可以先尝试用nutch mergeddb <修复后的crawldb路径> <原crawldb路径>修复CrawlDB，或者重新生成LinkDB（命令：nutch invertlinks <linkdb路径> -dir <segments目录>），之后再重启抓取任务。
• 爬虫配置限制了轮数：检查nutch-site.xml里的fetch.max.rounds参数，如果这个值被设置为1，那不管你怎么配置，爬虫只会执行一轮抓取就停止。确保这个参数的值大于你需要的抓取轮数。另外如果fetcher.max.crawl.delay设置得过高，会导致抓取速度极慢，看起来像是停止了，其实还在运行，记得去YARN控制台监控作业的实时进度。
• 批量DNS解析失败：如果第二轮待抓取的URL集中在某个域名，而这个域名突然无法解析，Nutch的fetcher可能会一直重试却不抛出明确错误，最终导致作业卡住。你可以查看nutch.log里的DNS相关日志，或者临时把这个域名加入过滤规则，测试下作业是否能继续运行。

内容的提问来源于stack exchange，提问作者Ravi Kiran