生产环境各组件调优总结

[ HDFS]

dfs.datanode.du.reserved 100g （计算方法 磁盘总容量*0.05+50g）其中50g适量即可
其他参数指定一些日志目录和datanode目录
rebalance阈值 2
不启用hdfs权限
启用zookeeper
还有一些进程的内存限制大小
记得配置HA
dfs.datanode.handler.count=30
dfs.namenode.handler.count=70
开启Service RPC端口
   在默认情况下，service RPC端口是没有使用的，client和DataNode汇报，zkfc的健康检查都会公用RPC Server，当client的请求量比较大或者DataNode的汇报量很大，会导致他们之间相互影响，导致访问非常缓慢，开启之后，DN的汇报和健康检查请求都会走Service RPC端口，避免了因为client的大量访问影响，影响服务之间的请求，在HA集群中，可以在hdfs-site.xml中设置

---

【Hbase】

服务端 
1.hbase.regionserver.handler.count：rpc请求的线程数量，默认值是10，生产环境建议使用100，也不是越大越好，特别是当请求内容很大的时候，	比如scan/put几M的数据，会占用过多的内存，有可能导致频繁的GC，甚至出现内存溢出。
2.hbase.master.distributed.log.splitting：默认值为true，建议设为false。关闭hbase的分布式日志切割，在log需要replay时，由master来负责重放
3.hbase.regionserver.hlog.splitlog.writer.threads：默认值是3，建议设为10，日志切割所用的线程数
4.hbase.snapshot.enabled：快照功能，默认是false(不开启)，建议设为true，特别是对某些关键的表，定时用快照做备份是一个不错的选择。
5.hbase.hregion.max.filesize：默认是10G， 如果任何一个column familiy里的StoreFile超过这个值, 那么这个Region会一分为二，因为region分裂会有短暂的region下线时间(通常在5s以内)，为减少对业务端的影响，建议手动定时分裂，可以设置为60G。
6.hbase.hregion.majorcompaction：hbase的region主合并的间隔时间，默认为1天，建议设置为0，禁止自动的major主合并，major合并会把一个store下所有的storefile重写为一个storefile文件，在合并过程中还会把有删除标识的数据删除，在生产集群中，主合并能持续数小时之久，为减少对业务的影响，建议在业务低峰期进行手动或者通过脚本或者api定期进行major合并。
7.hbase.hregion.memstore.flush.size：默认值128M，单位字节，一旦有memstore超过该值将被flush，如果regionserver的jvm内存比较充足(16G以上)，可以调整为256M。
8.hbase.hregion.memstore.block.multiplier：默认值2，如果一个memstore的内存大小已经超过hbase.hregion.memstore.flush.size * hbase.hregion.memstore.block.multiplier，则会阻塞该memstore的写操作，为避免阻塞，建议设置为5，如果太大，则会有OOM的风险。如果在regionserver日志中出现”Blocking updates for ‘’ on region : memstore size <多少M> is >= than blocking <多少M> size”的信息时，说明这个值该调整了。
9.hbase.hstore.compaction.min：默认值为3，如果任何一个store里的storefile总数超过该值，会触发默认的合并操作，可以设置5~8，在手动的定期major compact中进行storefile文件的合并，减少合并的次数，不过这会延长合并的时间，以前的对应参数为hbase.hstore.compactionThreshold。
10.hbase.hstore.compaction.max：默认值为10,一次最多合并多少个storefile，避免OOM。
11.hbase.hstore.blockingStoreFiles：默认为7，如果任何一个store(非.META.表里的s