- 操作系统 ：CentOS Linux 6.0（Final）
- 内核 ： Linux 2.6.32
- 硬件 ： HP 3300 Series MT ，内存增加到6G。
- Hadoop集群： 一台NameNode 同时作为client node、三台DataNode。数据备份为3分，即dif.replication = 3 。
笔者在测试hadoop性能过程中，在向hadoop集群中put大量数据（50G）的时候，集群中的datanode节点频繁宕机。并且在centos日志系统中没有关于datanode宕机的错误报告。
因为hadoop的测试数据是存放在namenode 中的，所以namenode同时也是client node。经过笔者观察发现，宕机的只是datanode，而client node从来不宕机。在hadoop put数据的过程中，通过ganglia观察到client node的系统负载率要要远远高于datanode 。繁忙的client node不宕机，而相对系统负载率低的datanode却频繁死机，说明了datanode宕机与cpu、内存无关。笔者将目光转向了磁盘I/O和网络I/O。
首先，考虑是否因为磁盘I/O频繁操作引起的datanode系统宕机。因为测试数据存放在client node上，所以要在clent node上进行大量的磁盘读取数据操作。client node不宕机，说明了出现的问题与磁盘读取数据操作无关。hadoop进行put操作，在datanode上只进行极少量的配置文件读取，主要是将数据进行磁盘写操作。为了测试是否是由磁盘写操作引起的系统宕机，笔者将集群中的所有datanode代码中写磁盘操作的部分注释掉，这样datanode在接收到数据后就不在进行磁盘写操作。但是，在hadoop集群运行put操作过程中，datanode依然宕机。那么，现在可以判定磁盘I/O不是造成宕机的原因。
那么，造成系统宕机的原因是不是因为网络I/O 呢？仔细观察整个集群中的网络I/O发现，因为client node要put数据，所以在client node节点上，有大量数据包发送到集群网络上，相比发送大量的数据包，client node接收到的应答包很小，基本可以忽略不计，在这里可以暂时做出以下结论，网络操作中的发送大量数据包不会使机器宕机。而对于datanode，因为handoop集群的数据块备份个数为3份，所以根据hadoop中生成备份数据的规则，每个datanode节点会同时发送和接送大量数据。笔者观察到一个有趣的现象：3台datanode节点不会全部宕机，最多只是其中两台宕机，剩下的那一台datanode节点能完成所有工作。这时候观察网络流量，因为宕掉了2台datanode节点，所以hadoop备份机制就不在工作，剩下的那台没有宕掉的datanode机器把接收到的数据写入磁盘就好了，不用再发送给其他datanode节点进行备份。也就是说最后剩下的那个datanode节点，只接收client node发送来的大量数据和发送可以忽略不计应答包。在这里笔者可以再次做一个暂时性结论，网络操作中的接收大量数据包不会使机器宕机。为了验证结论，笔者去掉了一台datanode节点，并再次修改了相应hadoop配置文件和datanode代码，用剩下的两个datanode节点A和B，其中一个datanode节点A接收client node发送过来的数据，并且再转发到另一个只接收数据datanode B节点上，然后节点A将数据写入磁盘。datanode B节点只接收datanode A节点发送来的数据，然后写入磁盘。这样datanode A节点在haodoop put过成中不仅接收数据，而且还发送数据。经过测试，datanode A节点频繁的死机。在这里笔者基本可以确定以下结论，造成datanode频繁宕机的原因是由于datanode节点通过网络同时接收和发送了大量的数据。
原因找到了，那么下一步就需要找到解决问题的方法，通过网络同时接收和发送大量数据的操作对应用程序来说是很基本和常见的操作，如果Centos因为这个操作就频繁的宕机，那么这个操作系统也就太脆弱了。笔记根据经验判断，这应该是硬件驱动程序不兼容引起的问题。况且笔者在安装Centos的时候，使用都是CentOS自带的驱动程序。而不是硬件厂商针对操作系统推出的驱动程序。有了这个想法后，笔者更新了集群中所有节点网卡驱动程序，然后再次运行hadoop put操作。终于，hadoop集群将50G的数据量写入了磁盘。
至此，困扰笔者十几日的问题解决了。
来源：oschina
链接：https://my.oschina.net/u/223061/blog/78351