问题导读
1、块恢复操作主要受哪些影响？
2、数据块恢复测试场景需要什么？
3、通过对Client与DataNode通信性能分析，读写小文件和性能有什么关系？
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磁盘效果应该会更好。
原文链接：http://www.aboutyun.com/thread-9349-1-1.html
