版权声明：本文为博主原创文章，未经博主允许不得转载。https://www.jianshu.com/p/84824af0ebd7
【1、zookeeper.session.timeout】
regionserver在zookeeper的会话过期时间。
如果regionserver在zookeeper.session.timeout配置的会话时间期内没有去连zookeeper，zookeeper会将该regionserver从zookeeper中摘除，该regionserver停止服务。
该值不能配置太小，原因是生产环境的regionserver内存都配置很大（256g），可以提高memstore和cache的大小，提高性能。但会引发新的潜在问题，regionserver内存配置大了后，jvm的内存回收时间也会变长，很有可能超过zookeeper.session.timeout参数值，导致zookeeper误认为regionserver挂掉而将该regionserver摘除。
该值也不能配置太大，首先java已支持g1gc方式回收内存，每次内存回收时间不会很长；其次生产环境不允许长时间的服务中断，该值若配置大了，容易造成一个regionserver服务真发生异常时，zookeeper不会摘除该regionserver，导致很多请求失败。
zookeeper.session.timeout目前生产环境配置为是1分钟，可调整为3分钟。
【2、hbase.regionserver.handler.count】
Regionserver能够处理的IO请求线程数。
该参数与内存息息相关。对于单次请求内存消耗较高的Big Put场景（大容量单次PUT或设置了较大cache的scan，均属于Big PUT）或regionserver内存紧张的情况，该值可以设置的小一些。
而对于单次请求内存消耗低，TPS要求很高的场景，可以设置相对大些，100~200，以提高regionserver性能。
hbase.regionserver.handler.count目前生产值是30，较小，可调整为100。
【3、file.block.cache.size】
heap内存的多少比例作为regionserver的cache，默认0.2。该值直接影响读性能。
还是要看场景，如果读比写多很多，该值设置在0.4~0.5足矣；如果读写均衡，0.3左右差不多；如果写比读多，就直接采用默认值0.2。
设置该值时还需同时考虑hbase.regionserver.global.memstore.upperLimit参数，该值是memstore占用heap的最大百分比，后面会讲，两个参数一个影响读，一个影响写，两值的和不能超过0.8，不然会有OOM风险。
目前生产这俩值都是0.4。
【4、hbase.hregion.max.filesize】
regionserver上单个region的最大存储空间。当单个region超过该值时，就会触发Region的split，拆分成更小的region。
HBase中数据一开始会写入memstore，当memstore大小达到一定阈值后，会flush到disk上而成为storefile。当storefile数量超过3时，会启动compaction过程将它们合并为一个storefile。这个过程中会删除一些timestamp过期的数据。而当合并后的storefile大小大于hfile默认的最大值时，会触发split动作，将它切分成两个region。
当hbase.hregion.max.filesize比较小时，好处是拆分region或compaction小region里的storefile速度很快，内存占用低，缺点是触发split的几率大，平均吞吐量也越大，而spilt的时候region会被offline，因此在split结束前，访问该region的请求将被block（阻止）。当大量的region同时发生split时，系统的整体访问服务将受到严重影响，因此该值若比较小会容易出现吞吐量及响应时间延迟现象。
当hbase.hregion.max.filesize比较大时，单个region中触发split的几率就变小了，大量region同时触发split的几率也较小，因此吞吐量较hfile.size小尺寸更加稳定些。但也不是没有缺憾，由于该值较大，region长期得不到spilt，做一次compact和split会产生较长时间的停顿，对应用的读写性能冲击非常大。另外，大region意味着较大的storefile，compaction时对内存也是一个挑战。
hbase.hregion.max.filesize默认值是256M，目前生产上配置的值是20G，该值是一个比较难达到的值，从某种程度上间接禁用了自动split，那么在需要做split时，选择一个访问量较低的时间点，进行手动spit，就能保证绝大多数时间平稳的读写性能。
【5、hbase.regionserver.global.memstore.upperLimit/hbase.regionserver.global.memstore.lowerLimit】
默认值：0.4/0.35
当单个region内所有memstore大小总和超过hbase.hregion.memstore.flush.size值时，会flush该region的所有memstore。Regionserver的flush是通过将请求添加一个队列，模拟生产消费模式来异步处理的，那么当队列来不及消费，产生大量积压请求时，可能会触发OOM。
upperlimit：该参数的作用就是为了防止内存占用过大，当regionserver内所有region的memstore占用内存总和达到heap的40%时，HBase会强制block所有更新并flush这些reion以释放所有memstore占用的内存。
lowerlimit：与upperlimit不同的地方在于，当regionserver内所有region的memstore占用内存总和达到heap的35%而非40%时，不flush所有的memstore。它会找一个memstore内存占用最大的region，做个别的flush。该值相当于是在所有region强制flush导致性能下降前的一道防线。在日志中关键字为"**Flush thread woke up with memory above low water"。
这俩值在生产上的配置为0.4/0.38，其中lowerLimit参数在CDH5.8之前的默认值是0.38，但是在CDH5.8~CDH5.9.1.3参数的意义发生了修改，需要乘以hbase.regionserver.global.memstore.upperLimit才为实际使用到heap的百分比值，那么为了保证使用到heap的38%触发flush，该值需调整到0.95。（0.4*0.95=0.38）
【6、hbase.hstore.compactionThreshold/hbase.hregion.majorcompaction】
hbase.hstore.compactionThreshold：执行compaction的storefile数量，默认是3。该值越小查询性能越好，但越小意味着compaction会更加频繁，而compaction本身也会花销资源。
hbase.hregion.majorcompaction：major compaction的周期，默认是7天。可设置为0，即禁止自动的major合并，可手工或通过脚本定期进行major合并，目前生产便是这么做的。major compaction与mini compaction的区别是major compaction会清除过期的历史版本数据，同时合并storefile，而mini compaction只做合并。
【7、hbase.regionserver.hlog.blocksize/hbase.regionserver.maxlogs】
当写数据时默认会在写memstore同时写入Write-ahead Log（WAL）。WAL中包含了所有已经写入Memstore但还未Flush到HFile的更改（edits）。
当memstore中数据还没有持久化而regionserver宕掉的时候，可以使用WAL进行数据恢复。当WAL变得很大的时候，恢复就需要更长的时间。因此，对WAL的大小会进行限制，当达到限制大小时，就会触发memstore的flush。
WAL的最大值由hbase.regionserver.hlog.blocksize*hbase.regionserver.maxlogs决定。一旦达到这个值，memstroe flush就会被触发。
由此可见，memstore flush的触发条件除了memstore.lowerLimit*heap，还有hlog.blocksize*hbase.regionserver.maxlogs。
一般来说，hbase在region达到128M时应自动触发flush，而目前从Regionserver Flush Queue Size可看到每个regionserver都在每隔1个半小时进行flush，（理想情况下，Memstore Flush Queue的size不能持续增长)，推测为hlog.blocksize*hbase.regionserver.maxlogs触发了memstore flush。然而我们一般都希望时通过前者触发memstore flush而非后者，因为通过WAL触发memstore flush可能会一次flush很多region，造成flush风暴。
因此blocksize (128 mb) * hbase.regionserver.maxlogs大小需要略大于 hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE，以保证不会提前发生flush。
目前生产上blocksize为128M，hbase.regionserver.maxlogs为32个，128*32=4096，hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE=0.4*32g*1024=13107,
blocksize* hbase.regionserver.maxlogs < hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE，因此需要修改hbase.regionserver.maxlogs为103。（13107/128=102）
