HDFS性能瓶颈分析

1.fsimage加载阶段,主要耗时的操作:
  1.1)FSDirectory.addToParent(),功能是根据路径path生成节点INode,并加入目录树中,占加载时间的73%;
  1.2)FSImage.readString和PermissionStatus.read操作是从fsimage的文件流中读取数据(分别是读取String和short)的操作,分别占加载时间的15%和8%;
优化方案:对fsimage的持久化操作采用多线程技术,为目录列表中的每个目录存储开辟一个线程,用来存储fsimage文件。主线程等待所有存储的子线程完毕后完成对fsimage加载。这样,存储时间将取决于存储最慢的那个线程,达到了提高fsimage加载速度的目的,从而在一定程度上提升了NameNode启动速度。
2.blockReport阶段,DataNode在启动时通过RPC调用NameNode.blockReport()方法, 主要耗时操作:
  2.1)FSNamesystem.addStoredBlock调用,对每一个汇报上来的block,将其于汇报上来的datanode的对应关系初始化到namenode内存中的BlocksMap表中,占用时间比为77%;此方法中主要耗时的两个阶段分别是FSNamesystem.countNode和DatanodeDescriptor.addBlock,后者是java中的插表操作,而FSNamesystem.countNode调用的目的是为了统计在BlocksMap中,每一个block对应的各副本中,有几个是live状态,几个是decommission状态,几个是Corrupt状态。
  2.2)DatanodeDescriptor.reportDiff,主要是为了将该datanode汇报上来的blocks跟namenode内存中的BlocksMap中进行对比,以决定那个哪些是需要添加到BlocksMap中的block,哪些是需要添加到toRemove队列中的block,以及哪些是添加到toValidate队列中的block,占用时间比为20%;
3.锁的竞争成为性能瓶颈
优化方案:其中锁内耗时的操作有FSEditLog.logXXX方法,可以考虑将FSEditLog的logXXX操作放到写锁外记录,但会引起记录的顺序不一致,可以通过在写锁内生成SerialNumber,在锁外按顺序输出来解决;
4.UTF8/Unicode转码优化成为性能瓶颈
优化方案:用SIMD指令的JVM Intrinsic转码实现,32bytes比目前Hadoop内pure Java实现快4倍,64bytes快十几倍。
5.RPC框架中,N个Reader将封装的Call对象放入一个BlockingQueue,N个Handler从一个BlockingQueue中提取Call对象,使得此BlockingQueue成为性能瓶颈
优化方案:采用多队列,一个Handler一个BlockingQueue,按callid分配队列。
6.sendHeartbeat阶段,在DataNode调用namenode.sendHeartbeat()方法时会DF和DU两个类,它们通过Shell类的runComamnd方法来执行系统命令,以获取当前目录的 df, du 值,在runComamnd方法中实质是通过java.lang.ProcessBuilder类来执行系统命令的。该类由JVM通过Linux 内核来fork 子进程,子进程当然会完全继承父进程的所有内存句柄,jstack看到JVM此时线程状态大部分处于WAITING, 这个过程会影响DFSClient写入超时,或关闭流出错。

你可能感兴趣的:(HDFS性能瓶颈分析)