背景描述
需求出发点是从Hbase和Hdfs优化开始。会影响性能的重要参数基本也都调过了。测试工具主要用的是YCSB和Hadoop自带的TestDfsIO来测俩服务的吞吐量及每秒传输量。参数怎么调吞吐量和每秒读写就是上不去。
问题发现
所以开始怀疑网络IO和磁盘IO这块是否存在瓶颈。用nload测网络IO，带宽也没有占满，就这点测试数据的传输量铁定够了。用FIO测磁盘IO。一共7个节点，结果问题出现了。每个节点随机读写和顺序读写的性能参差不齐。使用方法和参数解析网上一大堆，不讲述。
解决过程
开始了解磁盘的一些参数。主要是去调整/sys/block/sd*|vd*/queue这个目录下的参数，都是以文件形式存在的。 主要调 read_ahead_kb 和 nr_requests 预读和IO队列。反复修改反复压测找到一个平衡值。 一般/sys 这个目录没有写入权限，所以需要先赋权限，
bash chmod u+w /sys
另外 read_ahead_kb 需要 用 blockdev 来设置。
例如 ：blockdev --setra 8192 /dev/sda 设置值是文件值的两倍，这里设置8192，文件里会显示4096。
nr_requests 修改简单，用 echo 数值 > nr_requests 就可以，默认是128.可以适当提高。
总结
在一个集群中，当调整参数不能再提高性能的时候，就要考虑到是否再硬件层面上有没有达到瓶颈。像网络IO任务跑一下看看传输量再和自己的带宽测一下，如果说每个计算占用的网络IO把带宽都给占满了，那就是网络IO达到了瓶颈，没占满那继续测磁盘，磁盘IO测试最好是脱离所有的计算，关掉服务然后单纯的去测试磁盘。不用特别精准大概测几下做个平均看一下就行。目的是要看各个节点的读写性能是否再一个水平线上，一个写入达到100M，一个写入达到10M，会产生木桶效应。所以得先看一下一个集群中的每个节点之间的性能是否相似。得把低的先给优化好性能提上来。当然也不能排除磁盘坏道，碎片过多这类问题。
- 每个磁盘读写性能都测一下。
- 横向比较其他节点。
- 把性能低下的节点做一个分析。
- 如果是虚拟机，得看看宿主机的磁盘性能。宿主机本身磁盘性能没问题，但是虚拟机出问题了，那就得从虚拟机磁盘配置层面看看问题了。比如像KVM，配置没配好会产生性能损耗。
- 磁盘是否坏掉，是否有坏道，碎片是否占用过多。
- 不管是虚拟机参数还是系统内部的参数，每调整一个就去压测一下。一直调整到一个可接受的范围内。
