hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Baranau <alex.barano...@gmail.com>
Subject About HBase Memstore Flushes
Date Tue, 08 May 2012 20:00:47 GMT
Hi!

Just trying to check that I understand things correctly about configuring
memstore flushes.

Basically, there are two groups of configuraion properties (leaving out
region pre-close flushes):
1. determines when flush should be triggered
2. determines when flush should be triggered and updates should be blocked
during flushing

2nd one is for safety reasons: we don't want memstore to grow without a
limit, so we forbid writes unless memstore has "bearable" size. Also we
don't want flushed files to be too big. These properties are:
* hbase.regionserver.global.memstore.upperLimit &
hbase.regionserver.global.memstore.lowerLimit [1]   (1)
* hbase.hregion.memstore.block.multiplier [2]

1st group (sorry for reverse order) is about triggering "regular flushes".
As flushes can be performed without pausing updates, we want them to happen
before conditions for "blocking updates" flushes are met. The property for
configuring this is
* hbase.hregion.memstore.flush.size [3]
(* there are also open jira issues for per colfam settings)

As we don't want to perform too frequent flushes, we want to keep this
option big enough to avoid that. At the same time we want to keep it small
enough so that it triggers flushing *before* the "blocking updates"
flushing is triggered. This configuration is per-region, while (1) is per
regionserver. So, if we had constant (more or less) number of regions per
regionserver, we could choose the value in a such way that it is not too
small, but small enough. However it is usual situation when regions number
assigned to regionserver varies a lot during cluster life. And we don't
want to adjust it over time (which requires RSs restarts).

Does thinking above make sense to you? If yes, then here are the questions:

A. is it a goal to have more or less constant regions number per
regionserver? Can anyone share their experience if that is achievable?
B. or should there be any config options for setting up triggering flushes
based on regionserver state (not just individual regions or stores)? E.g.:
    B.1 given setting X%, trigger flush of biggest memstore (or whatever is
logic for selecting memstore to flush) when memstore takes up X% of heap
(similar to (1), but triggers flushing when there's no need to block
updates yet)
    B.2 any other which takes into account regions number

Thoughts?

Alex Baranau
------
Sematext :: http://blog.sematext.com/

[1]

  <property>
    <name>hbase.regionserver.global.memstore.upperLimit</name>
    <value>0.4</value>
    <description>Maximum size of all memstores in a region server before new
      updates are blocked and flushes are forced. Defaults to 40% of heap
    </description>
  </property>
  <property>
    <name>hbase.regionserver.global.memstore.lowerLimit</name>
    <value>0.35</value>
    <description>When memstores are being forced to flush to make room in
      memory, keep flushing until we hit this mark. Defaults to 35% of heap.
      This value equal to hbase.regionserver.global.memstore.upperLimit
causes
      the minimum possible flushing to occur when updates are blocked due to
      memstore limiting.
    </description>
  </property>

[2]

  <property>
    <name>hbase.hregion.memstore.block.multiplier</name>
    <value>2</value>
    <description>
    Block updates if memstore has hbase.hregion.block.memstore
    time hbase.hregion.flush.size bytes.  Useful preventing
    runaway memstore during spikes in update traffic.  Without an
    upper-bound, memstore fills such that when it flushes the
    resultant flush files take a long time to compact or split, or
    worse, we OOME.
    </description>
  </property>

[3]

  <property>
    <name>hbase.hregion.memstore.flush.size</name>
    <value>134217728</value>
    <description>
    Memstore will be flushed to disk if size of the memstore
    exceeds this number of bytes.  Value is checked by a thread that runs
    every hbase.server.thread.wakefrequency.
    </description>
  </property>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message