zoukankan      html  css  js  c++  java
  • HDFS APPEND性能测试

    hbase在写入数据之前会先写hlog,hlog目前是sequencefile格式,采用append的方式往里追加数据。之前团队的同学测试关闭hlog会一定程序上提升写hbase的稳定性。而在我之前的想象中,hlog的写入速度应该是稳定的。于是写了个append程序专门测试hdfs的append性能。

      代码如下:
    Java代码  收藏代码
    1. FSDataOutputStream stm = fs.create(path, true,  
    2.               conf.getInt("io.file.buffer.size"4096),  
    3.               (short)3, blocksize);  
    4. String a = make(1000);  
    5. stm.write(a.getBytes());  
    6. stm.sync();  

      可以看到,append的过程分两步:先write,然后执行sync(),如果不执行sync,理论上会存在丢失数据的风险。

      由于不清楚是sync不稳定,还是write本身不稳定。所以对打开和关闭sync均做了测试。
    图1:打开sync功能




    图2:关闭sync功能



        从图1和图2的结果可以看到打开和关闭sync操作同样不稳定,因此可以判断不稳定因素主要出在write本身上。观察write函数,发现在创建它时需要一个blocksize参数,我的代码中一开始是设置的1MB。于是修改为32MB,绝大部分毛刺消失了。进一步修改为64MB,性能有进一步的提升。如下图
    图3:设为32MB



    图4:设为64MB



      这个参数是决定多大的文件在hdfs上可读的。传统的hdfs写文件要满足dfs.block.size大小(默认64MB)才可读。但是在append模式下这个可读的大小是由这里的blocksize决定的。默认值在本地文件系统下由fs.local.block.size决定,在hdfs文件系统下仍由dfs.block.size决定。如果设为1MB,那么hdfs上每append 1MB的大小,就可以读到了。当写入的数据达到这个大小时,会触发namenode执行fsync()操作。而在日志中观察到,每次发生这个操作时,都会造成读响应的变慢。

      fsync()操作的内容比较多,没有仔细看源码,知道原理的同学联系我吧。

      从附图中可以看到,append_block_size从1MB提高到32MB,再提高到64MB,都会有一定程序的稳定性改善。再提高就没有用了,因为hlog和dfs.block.size的默认大小都是64MB。不过hbase每1s会强制刷新执行一次fsync,所以会看到hbase在打开日志的情况下每1s会有一次小的响应时间波动

      结论有两点:
      1 hdfs的append的确是有一点不稳定的
      2 修改fs.local.block.size或dfs.block.size可以影响这个不稳定因素。
  • 相关阅读:
    扩展运算符(Spread operator)
    增强的对象字面量,解构赋值
    ES6 模板字符串(template string)
    let和const
    svg实现放大效果
    svg制作风车旋转
    jquery实现某宝放大点击切换
    jQuery之文档处理
    jQuery之属性操作
    jQuery css操作
  • 原文地址:https://www.cnblogs.com/cl1024cl/p/6205183.html
Copyright © 2011-2022 走看看