今天抽空解决了一个Hadoop集群的一个非常有意思的故障，之所有有意思，是这个故障既可以称之为故障，又不算是故障，说不算问题吧，作业跑的特慢，说算问题吧，作业不但都能跑出来，还没有任何报错，所以还比较难查。

故障表象是一帮人嚷嚷作业太慢了，跑不动，但是基本上嚷嚷一会就能跑出来，但相对于原来还是慢。我看了下，确实比较慢，有些作业一个map要半小时，但不是所有作业都这样，部分作业就很快，没有什么规律可循。

好吧，我们来着手分析一下慢查询作业。因为解决以后都嗖嗖的跑完了，所以没有截图。以下完全靠文字描述。

在Yarn里打开某个被投诉慢的作业，进入AM的页面，一路进去到map页面，看到某个map，10多分钟了，才跑了0.2%，这必须不能忍。

  1. 复制该map的作业号。

  2. 进入该map所在的节点，查看该map attempt的进程号。

  3. 查看该进程的系统调用，看到该map进程建立了两个TCP连接，其中一个是某个DN的50010端口，好的，50010端口是数据块传输端口。

  4. 再检查几个慢的map进程，发现一个规律，这些慢的map进程都连接了同一个DN的50010。那么基本可以推定问题出在这个DN上。

  5. 登上这个DN，shutdown掉Datanode和Nodemanager。故障解除，任务又都飞起来了。

到这里故障是排除了，但是原因还不清楚，继续发掘原因。

由于只是慢，而不是完全跑不出来，大不了慢的map reduce attempt最后被kill掉了拿到其他服务器重新跑，但是不会报任何错误日志，系统log也没有错误日志。连WARN基本的都没有。但细心如我，还是发现了问题。

syslog里面的记录

Jun 19 14:05:45 6 kernel: bonding: bond0: link status definitely down for interface em1, disabling it
Jun 19 14:06:22 6 kernel: tg3 0000:01:00.0: em1: Link is up at 10 Mbps, full duplex
Jun 19 14:06:22 6 kernel: tg3 0000:01:00.0: em1: Flow control is off for TX and off for RX
Jun 19 14:06:22 6 kernel: tg3 0000:01:00.0: em1: EEE is disabled
Jun 19 14:06:22 6 kernel: bond0: link status definitely up for interface em1, 10 Mbps full duplex.

嗯，就是这个。