hadoop之HDFS:数据块恢复与文件上传测试
来源:互联网 发布:淘宝商品详情批量修改 编辑:程序博客网 时间:2024/06/05 22:31
1.数据块恢复
当某台机器上的一个DataNode进程down掉,HDFS为了保证文件的副本满足设定的副本数,会进行数据块的恢复操作。块恢复操作主要受两个参数影响:
a)dfs.namenode.replication.work.multiplier.per.iteration NameNode计算集群每个周期每个DataNode平均恢复的数据块数量;如果该参数配置得太小,则dfs.namenode.replication.max-streams配置得再大没有用;
b)dfs.namenode.replication.max-streams单个DataNode最大同时恢复的块数量,可以间接控制DataNode恢复数据块的带来的网络等压力;
同时,数据块恢复与文件系统读写文件一样,不会受限制移动数据块参数的限制,该参数做balance的时候才起作用:
hdfs dfsadmin -setBalancerBandwidth 62914563
1.1数据块恢复测试场景
以上所有测试场景文件大小为1MB,3台作为DataNode的机器为内存大小为16GB,网卡为1000Mb。(下面所有的网络图以最右边的一个波形图作为测试的网络值)
1.1.1 测试场景1
参数dfs.namenode.replication.max-streams=600,需要恢复数据块数量18016,两个DataNode节点参与恢复,则每个节点平均需要恢复9008。
开始时间:14:18
结束时间:14:27
则每个节点1分钟修复近1000个块,30个节点每分钟修复3000个块,那么3百万个块需要100分钟左右
从网卡的角度计算,每台机器1秒钟输出数据量为20MB,则1分钟输出数据量为20*60=1200MB,则10分钟输出流量为12000MB,因为一个文件大小为1MB,则大约为12000个文件,可能其中有些数据块出现过传输失败然后又重新传输,因此与评价每个节点修复9008个数据块差不多。
1.1.2 测试场景2
参数dfs.namenode.replication.max-streams=3000,需要恢复数据块数量24618,两个DataNode节点参与恢复,则每个节点平均需要恢复12308。
开始时间:16:07
结束时间:16:13
时间6分钟,每分钟完成2051(每3秒完成200个),30个节点每分钟完成61530,50分钟完成300万数据块修复。
该网络数据为测试场景1网卡数据的2倍,因此相同时间内完成数据量翻倍。
其中一台机器网络情况
由前两个测试结果可以看出,随着dfs.namenode.replication.max-streams配置参数增大,数据块恢复速度在加快,网络速度也在增加。
1.1.3 测试场景3
参数dfs.namenode.replication.max-streams=3000,需要恢复数据块数量34780,3个DataNode节点参与恢复,其中两个DataNode在同一台机器,所有单机器参与修复的线程可以达到3000*2个,则每个节点平均需要恢复11593。
开始时间:15:26
结束时间:15:41
共花费时间15分钟,平均每分钟每个节点772个块左右。
其中一台机器网络情况
由第三个测试可以看出,虽然有3有三个DataNode参与数据块修复,因为恢复的线程数量太多,导致部分数据块恢复超时,这部分数据块几分钟后需要重新恢复,多耗费了一段时间,从上图的第二个波形图可以看出,在15:33,输出的网络流量几乎变为0,大约4分钟后又有输出网络流量,如果忽略这部分时间,则恢复数据块花费时间为7分钟,则平均每个节点每分钟恢复数据块则为1656个块,是之前计算结果的2倍,因此同时运行的恢复数据块的线程数量不是越多越好。需要根据集群情况找一个合理值。
1.1.4 测试场景4
参数dfs.namenode.replication.max-streams=6000,需要恢复数据块数量25947,3个DataNode节点参与恢复,每个DataNode在单独的一台机器上,所有单机器参与修复的线程可以达到3000*2个,则每个节点平均需要恢复8649。
开始时间:10:32
结束时间:10:40
总耗时8分钟,每分钟每个节点修复1235
其中一台机器网络情况
由第三,四两个测试可以看出,虽然每个DataNode均有6000个线程参与数据块恢复,单台机器启动一个DataNode比单台机器启动多个DataNode性能要好,当然如果线程数相对比较小,因为两者结果大致相等。
2.单机器安装多DN测试
另外在单台机器上启动两个DataNode与启动一个DataNode的环境中,进行10KB大小文件大小的写测试,结果一样,通过观察网络数据,最大仅可达到13MB左右,根据之前对Client与DataNode通信性能分析,读写小文件过程中,更多的时间消耗在于磁盘交互,因此写小文件流量上不去,应该跟磁盘性能有关系,测试环境使用SATA盘,如果使用SSD,或SAS磁盘效果应该会更好。
- hadoop之HDFS:数据块恢复与文件上传测试
- hadoop之hdfs文件上传
- 数据采集之Web端上传文件到Hadoop HDFS
- Hadoop MapReduce之上传文件到HDFS
- hadoop数据上传hdfs出错
- HDFS数据块恢复算法的思考
- hadoop分析 - HDFS上传文件
- hadoop中hdfs文件上传
- Hadoop入门之HDFS上传和下载文件图解
- Hadoop笔记11之 Hadoop异常 hdfs.DFSClient(hdfs 不能上传文件)
- hadoop balancer 平衡hdfs文件块分布
- Hadoop之旅(2)—伪集群 HDFS 文件读取与上传案例、权限与安全模式
- 大数据之hadoop【hdfs】
- Hadoop-2.4.1源码分析--HDFS HeartBeat(心跳检测)之DataNode端数据块增量汇报
- Hadoop之——HDFS冗余数据块的自动删除
- hadoop的hdfs文件操作实现上传文件到hdfs
- HDFS之上传文件到hdfs中
- Hadoop之HDFS文件操作
- nginx已经重启后 无法访问页面
- C#实现将一个类序列化存储在数据库中
- 对Android Log进行了封装
- HDU 1671 Phone List(
- 深入研究B树索引-DML对B树索引的影响
- hadoop之HDFS:数据块恢复与文件上传测试
- 关于子网划分、子网聚合(超网)的研究
- ASCII,GB2312,GBK,GB18030,UNICODE各种编码关系由来
- 学习FreeRTOS前的准备工作
- mysql-5.6.14-winx64 中文乱码问题
- SDP协议分析
- Openstack Eventlet分析(2)
- C++获取本机的MAC地址
- CentOS6 配置svn+apache使用linux本地账户认证