Hadoop-HDFS 对性能造成重大影响的神秘杀手-Shell.

关于想了解HDFS的源码的朋友, 可以到蔡斌大哥那读读他的javaeye.

很抱歉, 我用了神秘杀手一词, 因为它实在害我太惨, 又花了好大精力才把它给拎出来。 

近来在测试Hadoop时, 使用NameNode身上的dfshealth.jsp 管理页面发现,DataNode在运行的过程中, Last Contact 参数时常会超过3。LC（Last Contact）的意思是表明DataNode有多少秒的时间未向NameNode发送心跳包了. 然而默认DataNode是3秒发送一次, 我们都知道，NameNode默认以10分钟作为DN的死亡超时时间，那么究竟有哪些因素会导致JSP管理页面LC参数超过3，甚至会达到200以上，这样的情况对我们的系统的稳定运行究竟有没有影响？
事实上，这现象我观察了好一阵子，影响LC参数增大的原因有下面几种情况：

1. HDFS收到大量删除BLOCK的命令. 请参见：https://issues.apache.org/jira/browse/HDFS-611；
2. HDFS 有大量BLOCK需要report 给NN；
3. 组织心跳包的数据；
4. 网络环境。

前两种情况LC的值一般不会超过100，对性能不会造成很大影响。 Hadoop-0.22.0 以后版本，Hadoop也有所改进。

那么值的一提的是DN在组织心跳包期间，对FSDatasetInterface 接口进行了相关方法的调用，具体可以参考一下FSDatasetMBean接口中的几个方法：

/**
   * Returns the total space (in bytes) used by dfs datanode
   * @return  the total space used by dfs datanode
   * @throws IOException
   */  
  public long getDfsUsed() throws IOException;
    
  /**
   * Returns total capacity (in bytes) of storage (used and unused)
   * @return  total capacity of storage (used and unused)
   * @throws IOException
   */
  public long getCapacity() throws IOException;

  /**
   * Returns the amount of free storage space (in bytes)
   * @return The amount of free storage space
   * @throws IOException
   */
  public long getRemaining() throws IOException;

这三个方法意思大家都很明白，它们的实现者分别为DF,DU两个类，它们会不定期的通过Shell类的runComamnd方法来执行系统命令，以获取当前目录的 df, du 值。
然而在执行的过程当中有趣的事情发生了，笔者有13个分区，一共存有14万多个BLOCK，
Df 和du 平均每次执行的时间都会超过两秒，戏剧性的是DU 和DF最高的一次在执行某分区目录的命令时，居然用了180秒以上。（Shell#runCommand方法中, 从ProcessBuilder 实例化到process.start() 执行时间）。

难道是分区目录下的BLOCK数量过多导致运行缓慢么，在linux 系统里执行DF DU相同的命令结果都是以毫秒时间结束。那问题显然出在了ProcessBuilder， 居了解，该类由JVM通过Linux 内核来fork 子进程，子进程当然会完全继承父进程的所有内存句柄，jstack看到JVM此时线程状态大部分处于WAITING， 这个过程经过测试确实会影响DFSClient写入超时，或关闭流出错（下篇会说到， 作为长久Running 的DFSClient， 应该做好流的关闭工作，0.21-trunk中流的关闭仍然存有安全隐患。） 最后我折腾过从32位机子一路换到64位的机子，但问题依然存在。

最后只好再次对HDFS开刀，重构了DU,DF 以及自己的IOStat , Uptime类，通过Linux系统来执行，把结果输出到临时文件中，然后由Hadoop来读取。 LC的问题不再发生。 当然有朋友遇到过，并且有解决方案的可以联系我 [e-mail] .

评论

7 楼 xiaoyao3857 2012-08-24  

看看你们的评论，收获不比看资料、正文收获小啊

6 楼 lance_123 2011-01-04  

david.org 写道

lance_123 写道

david.org 写道

lance_123 写道

这就是Java语言所带来的缺点的地方。

呃... 这个问题后来还是有了结论，我咨询过淘宝与腾讯，他们确实在DU,DF方面没有遇到我这样的问题。

问题的根源还是在于我在Datanode上使用了RAID阵列，导致磁盘IO的吞吐量大大降低。 从而在DU与DF过程中，导致系统IOWait激增。

哦，原来是这样的啊，DN上一般没必要使用阵列吧？为了节省空间？

嗯，是的。 让RAID保持两份副本，再使用非RAID硬盘保存一份。 在这样的情况下，不知道你有啥好的想法没？

其实只有二个副本，一个用RAID来维持，一个用非RAID来保存，多个DN共用阵列？你们数据量很大了？其实如果阵列失效很危险，还不如在上层采用RAID形式，DN中还是用JBOD，facebook是采用这种方法来保存历史且访问不频繁的数据。

5 楼 david.org 2011-01-04  

lance_123 写道

david.org 写道

lance_123 写道

这就是Java语言所带来的缺点的地方。

呃... 这个问题后来还是有了结论，我咨询过淘宝与腾讯，他们确实在DU,DF方面没有遇到我这样的问题。

问题的根源还是在于我在Datanode上使用了RAID阵列，导致磁盘IO的吞吐量大大降低。 从而在DU与DF过程中，导致系统IOWait激增。

哦，原来是这样的啊，DN上一般没必要使用阵列吧？为了节省空间？

嗯，是的。 让RAID保持两份副本，再使用非RAID硬盘保存一份。 在这样的情况下，不知道你有啥好的想法没？

4 楼 lance_123 2011-01-03  

david.org 写道

lance_123 写道

这就是Java语言所带来的缺点的地方。

呃... 这个问题后来还是有了结论，我咨询过淘宝与腾讯，他们确实在DU,DF方面没有遇到我这样的问题。

问题的根源还是在于我在Datanode上使用了RAID阵列，导致磁盘IO的吞吐量大大降低。 从而在DU与DF过程中，导致系统IOWait激增。

哦，原来是这样的啊，DN上一般没必要使用阵列吧？为了节省空间？

3 楼 david.org 2011-01-03  

lance_123 写道

这就是Java语言所带来的缺点的地方。

呃... 这个问题后来还是有了结论，我咨询过淘宝与腾讯，他们确实在DU,DF方面没有遇到我这样的问题。

问题的根源还是在于我在Datanode上使用了RAID阵列，导致磁盘IO的吞吐量大大降低。 从而在DU与DF过程中，导致系统IOWait激增。

2 楼 lance_123 2011-01-03  

这就是Java语言所带来的缺点的地方。

1 楼 caibinbupt 2010-03-30  

顶，这个结论来得不容易