来源：蜘蛛抓取(WebSpider)
时间：2016-09-26 09:32
标签：
regionserver 启动
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&您所在的位置： &
HBase数据库性能调优(1)
HBase数据库性能调优(1)
因官方Book Performance Tuning部分章节 没有按配置项进行索引，不能达到快速查阅的效果。所以我以配置项驱动，重新整理了原文，并补充一些自己的理解，如有错误，欢迎指正。
因官方Book Performance Tuning部分章节
没有按配置项进行索引，不能达到快速查阅的效果。所以我以配置项驱动，重新整理了原文，并补充一些自己的理解，如有错误，欢迎指正。
zookeeper.session.timeout
默认值：3分钟(180000ms)
说明：RegionServer与Zookeeper间的连接超时时间。当超时时间到后，ReigonServer会被Zookeeper从RS集群清单中移除，HMaster收到移除通知后，会对这台server负责的regions重新balance，让其他存活的RegionServer接管.
这个timeout决定了RegionServer是否能够及时的failover。设置成1分钟或更低，可以减少因等待超时而被延长的failover时间。
不过需要注意的是，对于一些Online应用，RegionServer从宕机到恢复时间本身就很短的(网络闪断，crash等故障，运维可快速介入)，如果调低timeout时间，反而会得不偿失。因为当ReigonServer被正式从RS集群中移除时，HMaster就开始做balance了
(让其他RS根据故障机器记录的WAL日志进行恢复)。当故障的RS在人工介入恢复后，这个balance动作是毫无意义的，反而会使负载不均匀，给RS
带来更多负担。特别是那些固定分配regions的场景。
hbase.regionserver.handler.count
默认值：10
说明：RegionServer的请求处理IO线程数。
这个参数的调优与内存息息相关。
较少的IO线程，适用于处理单次请求内存消耗较高的Big PUT场景(大容量单次PUT或设置了较大cache的scan，均属于Big
PUT)或ReigonServer的内存比较紧张的场景。
较多的IO线程，适用于单次请求内存消耗低，TPS要求非常高的场景。设置该值的时候，以监控内存为主要参考。
这里需要注意的是如果server的region数量很少，大量的请求都落在一个region上，因快速充满memstore触发flush导致的读写锁会影响全局TPS，不是IO线程数越高越好。
压测时，开启Enabling RPC-level logging
，可以同时监控每次请求的内存消耗和GC的状况，最后通过多次压测结果来合理调节IO线程数。
这里是一个案例 Hadoop and HBase Optimization for Read Intensive Search Applications
，作者在SSD的机器上设置IO线程数为100，仅供参考。
hbase.hregion.max.filesize
默认值：256M
说明：在当前ReigonServer上单个Reigon的最大存储空间，单个Region超过该值时，这个Region会被自动split成更小的region。
小region对split和compaction友好，因为拆分region或compact小region里的storefile速度很快，内存占用低。缺点是split和compaction会很频繁。
特别是数量较多的小region不停地split,
compaction，会导致集群响应时间波动很大，region数量太多不仅给管理上带来麻烦，甚至会引发一些Hbase的bug。
一般512以下的都算小region。
大region，则不太适合经常split和compaction，因为做一次compact和split会产生较长时间的停顿，对应用的读写性能冲击非常大。此外，大region意味着较大的storefile，compaction时对内存也是一个挑战。
当然，大region也有其用武之地。如果你的应用场景中，某个时间点的访问量较低，那么在此时做compact和split，既能顺利完成split和compaction，又能保证绝大多数时间平稳的读写性能。
既然split和compaction如此影响性能，有没有办法去掉?
compaction是无法避免的，split倒是可以从自动调整为手动。
只要通过将这个参数值调大到某个很难达到的值，比如100G，就可以间接禁用自动split(RegionServer不会对未到达100G的region做split)。
再配合RegionSplitter这个工具，在需要split时，手动split。
手动split在灵活性和稳定性上比起自动split要高很多，相反，管理成本增加不多，比较推荐online实时系统使用。
内存方面，小region在设置memstore的大小值上比较灵活，大region则过大过小都不行，过大会导致flush时app的IO
wait增高，过小则因store file过多影响读性能。
hbase.regionserver.global.memstore.upperLimit/lowerLimit
默认值：0.4/0.35
upperlimit说明：hbase.hregion.memstore.flush.size 这个参数的作用是
当单个memstore达到指定值时，flush该memstore。但是，一台ReigonServer可能有成百上千个memstore，每个
memstore也许未达到flush.size，jvm的heap就不够用了。该参数就是为了限制memstores占用的总内存。
当ReigonServer内所有的memstore所占用的内存总和达到heap的40%时，HBase会强制block所有的更新并flush这些memstore以释放所有memstore占用的内存。
lowerLimit说明：
同upperLimit，只不过当全局memstore的内存达到35%时，它不会flush所有的memstore，它会找一些内存占用较大的
memstore，做个别flush，当然更新还是会被block。lowerLimit算是一个在全局flush导致性能暴跌前的补救措施。为什么说是性能暴跌?可以想象一下，如果memstore需要在一段较长的时间内做全量flush，且这段时间内无法接受任何读写请求，对HBase集群的性能影响是很大的。
这是一个Heap内存保护参数，默认值已经能适用大多数场景。它的调整一般是为了配合某些专属优化，比如读密集型应用，将读缓存开大，降低该值，腾出更多内存给其他模块使用。
这个参数会给使用者带来什么影响?
比如，10G内存，100个region，每个memstore
64M，假设每个region只有一个memstore，那么当100个memstore平均占用到50%左右时，就会达到lowerLimit的限制。假设此时，其他memstore同样有很多的写请求进来。在那些大的region未flush完，就可能又超过了upperlimit，则所有
region都会被block，开始触发全局flush。
不过，除了你的内存非常小或你的应用场景里大多数都是读，我觉得不需要去调这个参数。
hfile.block.cache.size
默认值：0.2
说明：storefile的读缓存占用Heap的大小百分比，0.2表示20%。该值直接影响数据读的性能。
当然是越大越好，如果读比写少，开到0.4-0.5也没问题。如果读写较均衡，0.3左右。如果写比读多，果断默认吧。设置这个值的时候，你同时要参考
hbase.regionserver.global.memstore.upperLimit
，该值是memstore占heap的最大百分比，两个参数一个影响读，一个影响写。如果两值加起来超过80-90%，会有OOM的风险，谨慎设置。
hbase.hstore.blockingStoreFiles
说明：在compaction时，如果一个Store(Coulmn
Family)内有超过7个storefile需要合并，则block所有的写请求，进行flush，限制storefile数量增长过快。
block写请求会影响当前region的性能，将值设为单个region可以支撑的最大store
file数量会是个不错的选择，即允许comapction时，memstore继续生成storefile。最大storefile数量可通过 region
size/memstore size来计算。如果你将region size设为无限大，那么你需要预估一个region可能产生的最大storefile数。
hbase.hregion.memstore.block.multiplier
说明：当一个region里的memstore超过单个memstore.size两倍的大小时，block该region的所有请求，进行
flush，释放内存。虽然我们设置了memstore的总大小，比如64M，但想象一下，在最后63.9M的时候，我Put了一个100M的数据，此时
memstore的大小会瞬间暴涨到超过预期的memstore.size。这个参数的作用是当memstore的大小增至超过
memstore.size时，block所有请求，遏制风险进一步扩大。
这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景(不包括异常)不会出现突发写或写的量可控，那么保持默认值即可。如果正常情况下，你的写请求量就会经常暴长到正常的几倍，那么你应该调大这个倍数并调整其他参数值，比如hfile.block.cache.size和
hbase.regionserver.global.memstore.upperLimit/lowerLimit，以预留更多内存，防止HBase server
内容导航&第 1 页： &第 2 页：
关于的更多文章
MariaDB是一个向后兼容、替代MySQL的数据库服务器。它包含所有主
数据库产品
数据库综合
数据库新闻
维基百科将切换到另外一款开源数据库MariaDB
MariaDB是一个向后兼容、替代MySQL的数据库服务器。它
暮春三月，京师草长，杂花生树，群莺乱飞。ChinaHadoo
MySQL 5.6.10已经发布，Oracle将其称之为MySQL 5.6正
本书从一个网站制作过程入手，详细介绍基于ASP技术建设网站的全过程。全书共10章。第1章，网站制作规划与流程；第2章，IIS安装与
51CTO旗下网站大数据（6）
所有的用户数据以及元数据的请求，在经过Region的定位，最终会落在RegionServer上，并由RegionServer实现数据的读写操作。本小节将重点介绍RegionServer的代码结构和功能，从实现细节上深入理解RegionServer对于数据的操作流程。
1 RegionServer概述
RegionServer是HBase集群运行在每个工作节点上的服务。它是整个HBase系统的关键所在，一方面它维护了Region的状态，提供了对于Region的管理和服务；另一方面，它与Master交互，上传Region的负载信息上传，参与Master的分布式协调管理。具体如图(1)所示。
图(1) RegionServer的整体功能图
HRegionServer与HMaster以及Client之间采用RPC协议进行通信。HRegionServer向HMaster定期汇报节点的负载状况，包括RS内存使用状态、在线状态的Region等信息，在该过程中RS扮演了RPC客户端的角色，而HMaster扮演了RPC服务器端的角色。RS内置的RpcServer实现了数据更新、读取、删除的操作，以及Region涉及到Flush、Compaction、Open、Close、Load文件等功能性操作。此时，RS扮演了RPC服务的服务端的角色。RS与Client之间的RPC是HBase最为核心的操作，其服务状况的好坏，直接反映了RS内部、以及它所依赖的HDFS服务质量的好坏，因此，该过程的RPC经常成为分析读写性能异常的突破口。&
从RegionServer实现的功能上而言，除了与HMaster和Client之间的RPC通信之外，还包括如下几个重要的模块：&
（1）依托ZookeeperWatcher进行的分布式信息共享与任务协调的工作。&
MasterAddressTracker：捕获Master服务节点的变化。HBase使用多Master来解决Master单点故障的问题，主Master服务故障时，它与ZooKeeper的心跳延迟超过阈值，ZooKeeeper路径下的数据被清理，备Master上的ActiveMaserManager服务会竞争该Master路径，成为主Master。MasterAddresTracker是RS内部监听Master节点变化的追踪器。&
ClusterStatusTracker：HBase集群状态追踪器。该选项可以标识当前集群的状态，及它的启动时间。该设置选项有利于集群中的各个工作节点(RS)统一执行启动和退出操作。&
CatalogTracker：跟踪-ROOT-、.META.表的Region的状态。在HBase支持的-ROOT-、.META.、以及User Region三层树级目录结构中，-ROOT-、.META.表用来定位Region的位置，追踪-ROOT-表和.META.表对应Region的变化，可以时刻保证整个层次目录树的完整性。&
SplitLogWorker：基于Region的HLog文件切分器。在RS宕机之后，RS上的保存的HLog文件，需要按照Region进行切分。HMaster会把这些文件作为任务放置到Zookeeper的splitlog路径下，RS上SplitLogWorker会尝试获取任务，对获取到的HLog文件按照Region进行分组，处理的结果保存到相应Region的recovered.edits目录下。&
（2）Region的管理。&
Region是HBase数据存储和管理的基本单位。Client从.META.表的查找RowKey对应的Region的位置，每个Region只能被一个RS提供服务，RS可以同时服务多个Region，来自不同RS上的Region组合成表格的整体逻辑视图。
图(2) Region与RS逻辑关系图
RS内涉及到提供的有关Region维护的服务组件有：&
1） MemStoreFlusher，控制RS的内存使用，有选择性地将Region的MemStore数据写入文件。该组件可以有效地控制RS的内存使用，flush文件的速度在一定程度上可以反应HBase写服务的繁忙状况。&
2） CompactSplitThread，合并文件清理不需要的数据，控制Region的规模。在Store内的文件个数超过阈值时，触发Compact合并文件操作，一是清理被删除的数据，二是多余版本的清理。在Region内的Store文件大小超过阈值，会触发Region的Split操作，一个Region被切分成两个Region。这两个操作都是在CompactSplitThread的各自的线程池中被触发。&
3） CompactionChecker，周期性检查RS上的Region是否需要进行Compaction操作，确认需要进行Compaction操作的Region，提交给CompactSplitThread执行请求。&
RS的内存的使用分为MemStore和BlockCache。其中MemStore提供写操作的缓存，而BlockCache是提供的读请求缓存。它们详细的内容会在后续章节中介绍。&
（3）WAL的管理。&
HBase对于数据的更新和删除操作默认先Append到HLog文件，然后再更新到RS对应的Region上，因此，由HLog文件在RS的处理方式，被称为Write-Ahead-Log。多个Region的更新删除操作会被相继写入同一个文件，出于以下的原因，HLog文件会被截断，然后创建新HLog文件继续当前的Append操作。&
1） Append操作失败，避免因底层文件系统的文件异常，阻塞数据的操作。&
2） 降低存储空间的开销。当HLog上记录的数据完全从MemStore写入HDFS，此时如果多个HLog文件，有利于筛选冗余的HLog文件，提高存储空间的效率。&
3） 提高分布式HLog文件切分操作(Distributed Log Split)的效率。多个HLog文件就对应同样数目的LogSplit子任务，从而可以借助多个RS的SplitLogWorker组件快速完成HLog文件的切分，尽快恢复Region的服务。&
在RS内，LogRoller定期刷新出一个新的HLog文件。&
（4）Metrics&
Metrics对外提供了衡量HBase内部服务状况的参数。RegionServer内Metrics包含了内存使用、Region服务状况、Compaction、blockCache等一系列标识服务状况的参数。HBase Metrics继承Hadoop Metrics的实现，目前支持文件、Ganglia、以及数据流等多种输出方式，可以针对输出的Metrics信息灵活构建监控系统。&
（5）HttpServer&
RS内置了一个Jetty Web Server，用来对外提供RS的访问页面。访问页面目前支持实时Metrics信息查询、日志查询、线程的Dump、修改日志级别等操作。
2 RegionServer的启动过程分析
RegionServer服务由org.apache.hadoop.hbase.regionserver.HRegionServer类提供。该类实现了四个接口，分别是HRegionInterface，RegionServerServices，HBaseRPCErrorHandler和Runnable。其中，HRegionInterface定义了RS对外提供的RPC访问接口，通过RPCServer内置的Handler来处理请求；RegionServerServices定义了基于RS内部的服务信息接口，例如onlineRegions增、删、查接口，以及获取HLog、文件系统等接口；HBaseRPCErrorHandler定义了RPCServer异常状态检测处理接口；Runnable是Java库中的线程接口，实现该接口意味着RegionServer生命周期会运行在run()的函数体内。&
RegionServer是一个独立的服务，有一个main函数在启动时被调用，main函数内通过HRegionServerCommandLine的反射机制在JVM内动态加载RegionServer实现类，并按照args解析参数情况，决定启动或者关闭RS服务。
public class HRegionServer implements HRegionInterface,
HBaseRPCErrorHandler,, RegionServerServices {
public static void main([] args) throws
Configuration conf = HBaseConfiguration.create();
@SuppressWarnings(&unchecked&)
Class&? extends HRegionServer& regionServerClass = (Class&? extends HRegionServer&) conf
.getClass(HConstants.REGION_SERVER_IMPL, HRegionServer.class);
new HRegionServerCommandLine(regionServerClass).doMain(args);
初始化与执行过程包括：&
（1）构造HRegionServer实例，初始化变量和对象。这涉及到以下重要变量初始化：
protected volatile boolean stopped =//关闭Server的标识，关闭过程中会置成ture&
private boolean stopping =//关闭Region过程的标识，是进入stopped之前的状态&
protected volatile boolean fsOk;//文件系统状态标识，false表示文件系统不可用&
private final ConcurrentSkipListMap&byte[], Boolean& regionsInTransitionInRS =&
new ConcurrentSkipListMap&byte[], Boolean&(Bytes.BYTES_COMPARATOR);//RS内处于迁移过程中的Region，其中true表示在open，false表示在close&
protected final Map&String, HRegion& onlineRegions =&
new ConcurrentHashMap&String, HRegion&();//RS内正在服务的Region&
protected final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();//修改onlineRegions对象的读写锁&
protected final int threadWakeF//工作线程服务周期间隔&
private final int msgI//向Master汇报心跳，收集Metrics间隔&
private final long maxScannerResultS//Scanner执行next返回的数据量阈值，默认设置是Long.MAX_VALUE&
private int webuiport = -1;//webServer的端口号&
private //HRegiongServer初始化的时间，取自系统时间&
private ServerName serverNameFromMasterPOV;//标识Server的名字&
private final int rpcT//定义到HMaster之间的rpc超时时间
在RS上重要的对象列表，如表1所示。&
表1RegionServer重要对象的解释&
hbaseMaster
HMasterRegionInterface
RS向HMaster汇报信息，提供的RPC客户端
RS内的Rpc服务器
维护客户访问的租约
compactSplitThread
CompactSplitThread
RS内执行Compact和Split功能组件
cacheFlusher
MemStoreFlusher
负责将Region的MemStore写入文件
compactionChecker
定期检查Region的Compaction过程
接收Write-Ahead-Log
hlogRoller
定期开启新的HLog文件
（2）监听服务组件的初始化与执行。&
这个过程初始化以ZooKeeperWatcher为基础的服务，例如监听Master服务节点的MasterAddressManager，标识HBase集群状态的ClusterStatusTracker，以及元数据(-ROOT-, .META.)变化的监听器。启动这些服务可以保证整个集群信息协调一致。&
（3）RS服务组件的初始化与执行。&
这个过程是初始化compactSplitThread，cacheFlusher，compactionChecker，以及Leases。&
（4）尝试连接HMaster，注册RS到HMaster。&
（5）周期性收集Metrics和向Master发送心跳。
3 Store相关
Region是RS上的基本数据服务单位，用户表格由1个或者多个Region组成，根据Table的Schema定义，在Region内每个ColumnFamily的数据组成一个Store。每个Store内包括一个MemStore和若干个StoreFile(HFile)组成。如图(3)所示。本小节将介绍Store内的MemStore、StoreFile(HFile)的内部结构与实现。
图(3) Region-Store结构图
3.1 MemStore原理与实现分析&
MemStore是一个内存区域，用以缓存Store内最近一批数据的更新操作。对于Region指定的ColumnFamily下的更新操作(Put、Delete)，首先根据是否写WriteAheadLog，决定是否append到HLog文件，然后更新到Store的MemStore中。显然，MemStore的容量不会一直增长下去，因此，在每次执行更新操作时，都会判断RS上所有的MemStore的内存容量是否超过阈值，如果超过阈值，通过一定的算法，选择Region上的MemStore上的数据Flush到文件系统。更详细的处理流程图如图(4)。
图(4) 更新操作的流程图
MemStore类内的重要的成员变量：
volatile KeyValueSkipListSet kvset;
volatile KeyValueSkipListSet snapshot;
final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
final AtomicLong size;
TimeRangeTracker timeRangeTracker;
TimeRangeTracker snapshotTimeRangeTracker;
MemStoreLAB allocator;
注意 KeyValueSkipListSet是对于jdk提供的ConcurrentSkipListMap的封装，Map结构是&KeyValue,KeyValue&的形式。Concurrent表示线程安全。SkipList是一种可以代替平衡树的数据结构，默认是按照Key值升序的。对于ConcurrentSkipListMap的操作的时间复杂度平均在O(logn)，设置KeyValue. KVComparator比较KeyValue中Key的顺序。
写入MemStore中的KV，被记录在kvset中。根据JVM内存的垃圾回收策略，在如下条件会触发Full GC。&
 内存满或者触发阈值。&
 内存碎片过多，造成新的分配找不到合适的内存空间。&
RS上服务多个Region，如果不对KV的分配空间进行控制的话，由于访问的无序性以及KV长度的不同，每个Region上的KV会无规律地分散在内存上。Region执行了MemStore的Flush操作，再经过JVM GC之后就会出现零散的内存碎片现象，而进一步数据大量写入，就会触发Full-GC。图(5)显示这种假设场景的内存分配过程。&
图(5) 无处理状态下MemStore内存分配图
为了解决因为内存碎片造成的Full-GC的现象，RegionServer引入了MSLAB（HBASE-3455）。MSLAB全称是MemStore-Local Allocation Buffers。它通过预先分配连续的内存块，把零散的内存申请合并，有效改善了过多内存碎片导致的Full GC问题。&
MSLAB的工作原理如下：&
 在MemStore初始化时，创建MemStoreLAB对象allocator。&
 创建一个2M大小的Chunk数组，偏移量起始设置为0。Chunk的大小可以通过参数hbase.hregion.memstore.mslab.chunksize调整。&
 当MemStore有KeyValue加入时，maybeCloneWithAllocator(KeyValue)函数调用allocator为其查找KeyValue.getBuffer()大小的空间，若KeyValue的大小低于默认的256K，会尝试在当前Chunk下查找空间，如果空间不够，MemStoreLAB重新申请新的Chunk。选中Chunk之后，会修改offset=原偏移量+KeyValue.getBuffer().length。chunk内控制每个KeyValue大小由hbase.hregion.memstore.mslab.max.allocation配置。&
 空间检查通过的KeyValue，会拷贝到Chunk的数据块中。此时，原KeyValue由于不再被MemStore引用，会在接下来的JVM的Minor GC被清理。
注意 设置chunk的默认大小以及对于KeyValue大小控制的原因在于，MSLAB虽然会降低内存碎片造成的Full-GC的风险，但是它的使用会降低内存的利用率。如果超过一定大小的KeyValue，此时该KeyValue空间被回收之后，碎片现象不明显。因此，MSLAB只解决小KV的聚合。
MSLAB解决了因为碎片造成Full GC的问题，然而在MemStore被Flush到文件系统时，没有reference的chunk，需要GC来进行回收，因此，在更新操作频繁发生时，会造成较多的Young GC。&
针对该问题，HBASE-8163提出了MemStoreChunkPool的解决方案，方案已经被HBase-0.95版本接收。它的实现思路：&
 创建chunk池来管理没有被引用的chunk，不再依靠JVM的GC回收。&
 当一个chunk没有引用时，会被放入chunk池。&
 chunk池设置阈值，如果超过了，则会放弃放入新的chunk到chunk池。&
 如果当需要新的chunk时，首先从chunk池中获取。&
根据patch的测试显示，配置MemStoreChunkPool之后，YGC降低了40%，写性能有5%的提升。如果是0.95以下版本的用户，可以参考HBASE-8163给出patch。
思考 通过MemStore提供的MSLAB和MemStoreChunkPool给出的解决方案，可以看出在涉及到大规模内存的Java应用中，如何有效地管理内存空间，降低JVM GC对于系统性能造成的影响，成为了一个研究热点。整体上来说，一是设置与应用相适应的JVM启动参数，打印GC相关的信息，实时监控GC对于服务的影响；二是从应用程序设计层面，尽可能地友好地利用内存，来降低GC的影响。
在ChunkPool就是帮助JVM维护了chunk信息，并把那些已经不再MemStore中的数据的chunk重新投入使用。这样就可以避免大量的YGC。
3.2 MemStore参数控制原理与调优&
对于任何一个HBase集群而言，都需要根据应用特点对其系统参数进行配置，以达到更好的使用效果。MemStore作为更新数据的缓存，它的大小及处理方式的调整，会极大地影响到写数据的性能、以及随之而来的Flush、Compaction等功能。这种影响的原因在于以下两个方面。&
 RS全局的MemStore的大小与Region规模以及Region写数据频度之间的关系。&
 过于频繁的Flush操作对于读数据的影响。&
这其中涉及到的可调整的参数如下表。&
表MemStore相关的配置参数&
默认值
hbase.regionserver.global.memstore.upperLimit
RS内所有MemStore的总和的上限/Heap Size的比例，超过该值，阻塞update，强制执行Flush操作。
hbase.regionserver.global.memstore.lowerLimit
执行Flush操作释放内存空间，需要达到的比例。
hbase.hregion.memstore.flush.size
每个MemStore占用空间的最大值，超过该值会执行Flush操作。
hbase.hregion.memstore.block.multiplier
HRegion的更新被阻塞的MemStore容量的倍数。
hbase.hregion.preclose.flush.size
关闭Region之前需要执行Flush操作的MemStore容量阈值。
对于上述参数理解：&
（1）RS控制内存使用量的稳定。&
例如，假设我们的RS的内存设置为10GB，按照以上参数的默认值，RS用以MemStore的上限为4GB，超出之后，会阻塞整个RS的所有Reigon的请求，直到全局的MemStore总量回落到正常范围之内。&
以上涉及到cacheFlusher在MemStore总量使用超过上限时，选择Region进行Flush的算法，由MemStoreFlusher.flushOneForGlobalPressure()算法实现。算法的处理流程如下。&
关键的数据结构：
SortedMap&Long,HRegion& regionsBySize =
server.getCopyOfOnlineRegionsSortedBySize();
excludedRegions = new ();
HRegion bestFlushableRegion = getBiggestMemstoreRegion(
regionsBySize, excludedRegions, true);
HRegion bestAnyRegion = getBiggestMemstoreRegion(
regionsBySize, excludedRegions, false);
步骤1：RS上在线的Region，按照当前MemStore的使用量进行排序，并存储在regionsBySize中。&
步骤2：选出Region下的Store中的StoreFile的个数未达到hbase.hstore.blockingStoreFiles，并且MemStore使用量最大的Region，存储到bestFlushableRegion。&
步骤3:选出Region下的MemStore使用量最大的Region，存储到bestAnyRegion对象。&
步骤4：如果bestAnyRegion的memstore使用量超出了bestFlushableRegion的两倍，这从另外一个角度说明，虽然当前bestAnyRegion有超过blockingStoreFiles个数的文件，但是考虑到RS内存的压力，冒着被执行Compaction的风险，也选择这个Region作为regionToFlush，因为收益大。否则，直接选择bestFlushableRegion作为regionToFlush。&
步骤5：对regionToFlush执行flush操作。如果操作失败，regionToFlush放入excludedRegions，避免该Region下次再次被选中，然后返回步骤2执行，否则程序退出。
（2）设置两个limit，尽可能减少因为控制内存造成数据更新流程的阻塞。&
当RS的MemStore使用总量超过(Heap*hbase.regionserver.global.memstore.lowerLimit)的大小时，同样会向cacheFlusher提交一个Flush请求，并以（1）中Region选择算法，对其进行Flush操作。与（1）不同，这个过程中RS不会阻塞RS的写请求。&
因此，在生产环境中，我们肯定不希望更新操作被block，一般会配置(upperLimit –lowerlimit)的值在[0.5,0.75]之间，如果是应用写负载较重，可以设置区间内较大的值。
本系列文章属于在个人技术博客原创，原文链接为,
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：4385次
排名：千里之外
转载：12篇
