hbase region与内存的关系

http://hbase.apache.org/book.html#ops.capacity.regions.count

In production scenarios, where you have a lot of data, you are normally concerned with the maximum number of regions you can have per server. too many regions has technical discussion on the subject. Basically, the maximum number of regions is mostly determined by memstore memory usage. Each region has its own memstores; these grow up to a configurable size; usually in 128-256 MB range, see hbase.hregion.memstore.flush.size. One memstore exists per column family (so there’s only one per region if there’s one CF in the table). The RS dedicates some fraction of total memory to its memstores (see hbase.regionserver.global.memstore.size). If this memory is exceeded (too much memstore usage), it can cause undesirable consequences such as unresponsive server or compaction storms. A good starting point for the number of regions per RS (assuming one table) is:

((RS memory) * (total memstore fraction)) / ((memstore size)*(# column families))

This formula is pseudo-code. Here are two formulas using the actual tunable parameters, first for HBase 0.98+ and second for HBase 0.94.x.

HBase 0.98.x
((RS Xmx) * hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size * (# column families))
HBase 0.94.x
((RS Xmx) * hbase.regionserver.global.memstore.upperLimit) / (hbase.hregion.memstore.flush.size * (# column families))+

If a given RegionServer has 16 GB of RAM, with default settings, the formula works out to 16384*0.4/128 ~ 51 regions per RS is a starting point. The formula can be extended to multiple tables; if they all have the same configuration, just use the total number of families.

时间: 2024-10-31 09:19:25

hbase region与内存的关系的相关文章

HBase Region的flush过程

触发region flush的因素有很多,如手动触发,memstore压力触发,memstore到达限制触发,flush时间触发等. regionserver的flush由 flush实际操作步骤为 1.获得region写锁,将region的所有store执行prepare,产生snapshort,释放region写锁 2.将region的所有store执行flushcache,将数据写入hdfs中的一个或多个临时文件中 3.将临时文件移到region/store相应的目录下,删除memstor

资源加载卸载与内存的关系

22 关于Resources.load和实例化与内存的关系: 1.加载,单纯的Resources.load后消耗的内存很低,可能只是基础的引用预载.当对象被实例化后才会占用大量内存,当实例化多个对象后和实例化一个相差不大,可能后边实例的对象引用了第一个. 2.卸载,单纯的把所有实例的obj给destroy后,内存不会释放,但是再次实例也不会耗内存,若Object b = Resources.Load("Canvas");这样写,还需要把b=null后再调用Resources.Unloa

hbase region, store, storefile和列簇,的关系

先来一张大图. Hbase上Regionserver的内存分为两个部分,一部分作为Memstore,主要用来写:另外一部分作为BlockCache,主要用于读数据:这里主要介绍写数据的部分,即Memstore.当RegionServer(RS)收到写请求的时候(writerequest),RS会将请求转至相应的Region.每一个Region都存储着一些列(a set of rows).根据其列族的不同,将这些列数据存储在相应的列族中(Column Family,简写CF).不同的CF中的数据存

Hbase Region Server整体架构

Region Server的整体架构 本文主要介绍Region的整体架构,后续再慢慢介绍region的各部分具体实现和源码 RegionServer逻辑架构图 RegionServer职责 1.      监听协作,通过zk来侦听master.meta位置.集群状态等信息的变化,更新本地数据. 2.      管理region的offline.online.open.close等操作,这些操作是和hmaster配合这来做的,region的状态有如下这些 offline.opening.open.

浅析HBase region的单点问题

很长一段时间以来,一个region同一时间只能在一台RS(Region Server)中打开.如果一个region同时在多个RS上打开,就是multi-assign问题,会导致数据不一致甚至丢数据的情况,这是要避免和解决的.对于正常情况而言,region本质上是单点服务的,当RS宕机时,这个RS上的region无法提供服务,直到他们在另外的RS上重新上线为止.我们首先讨论这种单点服务会导致哪些问题,然后,看看有什么解决方案. region单点导致的问题 从正常和异常两个方面对region单点可能

关于CPU位数,OS位数以及内存大小关系的一点总结

(这个学期做助教,说来好惭愧啊,虽然我也是考研进来的,但是就在两年前复习的资料居然全部都忘光了.对大二的孩子们提问的问题多半都解决不了!!!越来越觉得自己的学习方法有问题了,总是想着一些知识能够根据自己多看几遍印象就深刻了,或者说每次记忆知识时总是想下次再记在脑海里吧!这样导致很多东西必须看资料才能想起来:啊原来是这样的,我看过啊,我知道的啊!这样的陋习一定要赶紧改正了,每次学习一个新的知识,都要记在脑海里,深刻地理解一下!!!) 1. CPU位数:一个时钟周期内处理器处理的二进制位数. CPU

Hbase region 某个regionserver挂掉后的处理

现象描述:某个regionserver服务挂掉后,此节点的Regions为0. 重启及数据恢复过程如下:() 切记在hadoop用户下: 第一步启动regionserver /hbaseStallDir/bin/graceful_stop.sh 192.168.5.164 /hbaseStallDir/bin/hbase-daemon.sh start regionserver /app/cloud/hadoop/bin/hadoop-daemon.sh start datanode 第二部:启

HBASE REGION SPLIT策略

hbase 0.94.0版本中,对于region的split方式引入了一个非常方便的SplitPolicy,通过这个SplitPolicy,可以主动的干预控制region split的方式.在org.apache.Hadoop.hbase.regionserver包中,可以找到这么几个自带的splitPolicy: ConstantSizeRegionSplitPolicy, IncreasingToUpperBoundRegionSplitPolicy, and KeyPrefixRegion

CPU 和 内存的关系(一)

本文以一个现代的.实际的个人电脑为对象,分析其中CPU(Intel Core 2 Duo 3.0GHz)以及各类子系统的运行速度--延迟和数据吞吐量.通过粗略的估算PC各个组件的相对运行速度,希望能给大家留下一个比较直观的印象.本文中的数据来自实际应用,而非理论最大值.时间的单位是纳秒(ns,十亿分之一秒),毫秒(ms,千分之一秒),和秒(s).吞吐量的单位是兆字节(MB)和千兆字节(GB).让我们先从CPU和内存开始,下图是北桥部分: 第一个令人惊叹的事实是:CPU快得离谱.在Core 2 3