SliveTest可以给Namenode带来很大的压力，用来做极限情况下的压力测试非常合适。吴威大师（给大师拎包一直是我的荣幸）在SliveTest基础上更上一层，设计了多线程的SliveMapper，在多map多线程下压测Namenode，由于使用了上一篇文章中提到的应用MapReduce进行多机联合负载的思想，基本上可以将Namenode的极限性能完全压榨干净。大师制作的这个工具运行起来之后，Namenode会处于一种假死状态，对其他rpc请求基本上失去响应，模拟出来的并发压力远远超过云梯当前线上的实际大压力。作为每次云梯新版本上线前的必测工具，检测出的Hadoop性能瓶颈或发现的相关bug无数。（大师的思想有如茫茫大海中的明灯，指引我们前进的方向）
　　DFSIO
　　DFSIO是一个标准的HDFS的Benchmark工具，位于test包中。功能简单明了，测试的是读和写的性能指标。使用参数如下：

　　该工具作为一个辅助性质的性能测试工具，基本上可测可不测，因为优点已经被前述几个工具占光了，这个工具中规中矩，没什么好说的。
　　共性与注意点
　　大致介绍了那么几种性能测试工具，共性也可以抽象出来，HDFS的性能测试追求的是检测Namenode在正常环境、高负载环境下的性能表现。吞吐率是HDFS性能的一个重要指标，但是与传统单机文件系统的测试结果获取方法不同之处在于，我们通过HDFS代码中集成的ganglia相关模块来收集HDFS的性能指标，监控诸如total_iops、RpcProcessingTime_avg、Syncs_num_ops等指标。有关ganglia以及监控指标的相关内容，将在下一弹《指标监控工具浅谈》中进行分享。
　　此外，进行HDFS性能测试的时候，有一些外界环境条件也是需要注意的。首要之一是不能启动SecondaryNamenode，这是因为SecondaryNamenode会同步editlog，或者做checkpoint，这都将占用Namenode的带宽和cpu资源，将干扰到性能测试获取到的结果数据。其次，为了降低环境因素的干扰，诸如RaidNode、Balancer等都不应该在性能测试中启动。HDFS文件系统中存在大量数据和没有数据测出来的性能测试结果也是有差异的，不能用来做性能对比，这是因为在文件目录结构树中的查找也会消耗一定的系统资源。
　　理想的情况是准备一套干净的只有Namenode和Datanode两种角色的HDFS文件系统，然后将上述测试工具放在这个环境中运行获取测试结果，用这个结果来与以前的版本做对比来获得对新版本性能优劣的评价。
　　压力测试
　　前述工具更关注性能方面的测试，实际上，性能和压力总是像一对亲兄弟，经常出现在同样的测试环境中。对于压力测试，我们通过制造大量的block、文件以及数据量来达到目的。测试团队自己设计制作了线上压力仿真工具，同样采用上一篇提到的技术，可以在短短的内将block数、文件数造到和线上一致。使得Namenode节点庞大的内存资源被占用去80%以上（本文由于公开发表，相关数据不便公开）。然后再在这样的环境下使用性能测试工具检测HDFS的性能。云梯测试环境对于线上压力的仿真能力非常有限，经过测算仿真的上限基本上是1:10的关系，即100台机器集群可以仿真1000台的实际环境。这里瓶颈不在Namenode，而是在Datanode上，由于机器少，block分散在Datanode上会占用更多的内存、cpu资源，datanode的吞吐率也会下降，这样一来性能测试受datanode性能的影响无法发挥大作用，测试结果失去参考价值。
　　总结
　　HDFS下常用的性能压测工具不仅有本文提及的几种，还有如“nnbench”，“randomwriter”，“randomtextwriter”等可以使用。本文所提及的则是具代表性的几种常用测试工具。海量数据的性能测试一直是这个领域的焦点，从熟悉这些工具入手，我们可以更快的切入到这个领域中。性能测试是一个说不完的话题，相关讨论也是层出不穷，本文至此收尾，谨以此文作为触摸Hadoop两年来的一个总结。