当前位置:  首页  >  服务器技术  >  Linux/unix  >  Linux教程

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

在测试Hadoop时,使用NameNode身上的dfshealth.jsp管理页面发现,DataNode在运行的过程中,LastContact参数时常会超过3。LC(LastContact)的意思是表明DataNode有多少秒的时间未向NameNode发送心跳包了。然而默认DataNode是3秒发送一次,我们都知道,NameN

在测试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接口中的几个方法:

  1. /** 
  2.    * Returns the total space (in bytes) used by dfs datanode 
  3.    * @return  the total space used by dfs datanode 
  4.    * @throws IOException 
  5.    */    
  6.   public long getDfSUSEd() throws IOException;  
  7.       
  8.   /** 
  9.    * Returns total capacity (in bytes) of storage (used and unused) 
  10.    * @return  total capacity of storage (used and unused) 
  11.    * @throws IOException 
  12.    */  
  13.   public long getCapacity() throws IOException;  
  14.   
  15.   /** 
  16.    * Returns the amount of free storage space (in bytes) 
  17.    * @return The amount of free storage space 
  18.    * @throws IOException 
  19.    */  
  20.   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的问题不再发生。

吐了个 "CAO" !
扫码关注 PHP1 官方微信号
PHP1.CN | 中国最专业的PHP中文社区 | PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | PHP问答
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved PHP1.CN 第一PHP社区 版权所有