（一）. 操作系统
1. 足够大的内存
2. 操作系统64位，jdk64位
3. 设置linux swap空间的swappiness=0
a1. 永久有效设置（需系统重启） sudo
vim /etc/sysctl.conf 在这个文档的最后加上这样一行:
vm.swappiness=0
a2. 临时修改 sudo
sysctl vm.swappiness=0
4. CPU
Make sure you have set up your
Hadoop to use native, hardware checksumming. See link:[hadoop.native.lib]
(二). 网络
1. 考虑数据传输,带宽足够大(因为主要和datanode节点之间做数据传输)
(三). Java
1. GC优化
a. CMS failure modes问题
尽可能早的启动CMS, -XX:CMSInitiatingOccupancyFraction=60~70 (备注：阈值越低，gc频繁，cpu使用率高)
b. old generation heap fragmentation brought问题(备注：因Region flush导致的内存碎片问题造成小内存块无法使用，从而引起fullgc时间过长超过regionserver向hmaster心跳时间，最终导致regionserver误判为挂掉)
hbase.hregion.memstore.mslab.enabled=true // 开启MSLAB (备注: 内存小或单个server上region数少的情况下，可关闭)
hbase.hregion.memstore.mslab.chunksize=2m // chunk的大小，越大内存连续性越好，但内存平均利用率会降低
hbase.hregion.memstore.mslab.max.allocation=256K // 通过MSLAB分配的对象不能超过256K，否则直接在Heap上分配，256K够大了
写负载高场景--降低YGC的开销---两种调整参数方式:
A). hbase.hregion.memstore.chunkpool.maxsize=0.5 (备注: ; 0为禁用: 作用: 降低YGC的开销，reuse chunk; 赋值区间为global
memstore size的百分比0-1之间 )
B). -XX:PretenureSizeThreshold=？（备注： 作用：有对象的size超过该值，直接在老年代分配内存，避免大对象在s0-s1之间copy; 值设置略小于hbase.hregion.memstore.mslab.chunksize的值即可）
c. enabling the off-heap Block Cache
A). LruBlockCache （备注：全部使用的是Java heap； 默认）
B). BucketCache (备注: 尽量缓存数据在 off-heap)
(四). Hbase配置调整(根据监控或压测情况，谨慎调整)
1.
2. (hdfs-default.xml) dfs.datanode.failed.volumes.tolerated(备注：datanode可以忍受的磁盘损坏的个数)
3. hbase.regionserver.handler.count(regionServer 处理客户端请求的线程数)
4. hfile.block.cache.size(备注： RegionServer 内存读)
5. Prefetch Option for
Blockcache (备注： 快速读)
6. hbase.regionserver.global.memstore.size(设置过小，会造成RS响应迟钝或频繁的compaction)
7. hbase.regionserver.global.memstore.size.lower.limit
8. hbase.hstore.blockingStoreFiles
9. hbase.hregion.memstore.block.multiplier
10. hbase.regionserver.checksum.verify (启用hbase的checksum，替代hdfs的)
11. Tuning callQueue Options(备注: 至少有一个写队列)
A). hbase.ipc.server.num.callqueue > 1
B). hbase.ipc.server.callqueue.read.ratio(0-1之间)
C). hbase.ipc.server.callqueue.scan.ratio(0-1之间;;; 备注: determine the ratio of read queues used for Gets and Scans; 至少有一个get队列)
D). hbase.ipc.server.callqueue.handler.factor (备注： 0为所有的handler共用一个queue； 1为一个handler一个queue; 0-1之间，比如0.5为两个handler共享一个queue;;; 影响：一个handler只处理他负责的queue，如果配置一个handler一个queue，则有长时间运行task的队列，不能有已经空闲的handler来帮忙处理，只能负责他的handler独自苦逼处理)
12. ZooKeeper (保证有一个专用的磁盘，具体看zooKeeper配置)
13. Schema Design
A). 列簇数决策（hbase官方说明一个列簇可以避免写多读少的场景下，多个列簇，在flush和compaction以region为单位的情况下，单个columnFamily达到数据量上限，造成所有columnFamily都被flush，从而引起频繁的compaction，造成IO浪费；如果某些列被经常查询，在读多写少的场景下，把这些列单独建立一个列簇，提高访问性能）
B). rowkey(设计尽可能短和保证查询效率),列簇名和列名尽可能短
C). region个数决策(备注: region数越少，集群运行越流畅； 一般20-200个比较合理)，最好建表的时候，Pre-splitting
1). region个数计算公式（HBase 0.98.x）: ((RS
Xmx) * hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size * (# column families))
D). 手动管理split和compaction，根据业务忙闲来灵活调整，避免自动管理，影响业务
E).