hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Daniel Cryans <jdcry...@apache.org>
Subject Re: Latency related configs for 0.90
Date Thu, 28 Apr 2011 00:13:07 GMT
I have a hard time digesting this... You ran the script, didn't change
anything else, ran the test and everything was back to normal, right?
Did you restart HBase or moved .META. around? The reason I'm asking is
that this script doesn't have any effect until .META. is reopened so I
would be quite flabbergasted to learn that _just_ running the script
makes things faster.

Another thing that's weird is that that setting for .META. has been
there since 0.20.0 so if it's the cause then it should have been the
same with 0.89

Hope we can resolve this mystery.


On Mon, Apr 25, 2011 at 4:01 PM, George P. Stathis <gstathis@traackr.com> wrote:
> Quick update:
> It turns out that we needed to run bin/set_meta_memstore_size.rb (
> http://hbase.apache.org/upgrading.html) . I'm curious though: I understand
> that our legacy dev machine would suffer because of the old
> MEMSTORE_FLUSHSIZE setting. But we setup a brand new dev box with a pristine
> 0.90 version that had no legacy MEMSTORE_FLUSHSIZE setting. Why would that
> instance have been affected? I looked at the -ROOT- table before I ran the
> script and there was no MEMSTORE_FLUSHSIZE setting. As soon as I execute the
> script and re-run the unit tests, they all started passing again. Also, the
> legacy hbase instances running on our dev laptops didn't have the script
> executed against them. Why would they work without it?
> Anyway, trying to understand for future reference.
> -GS
> On Thu, Apr 21, 2011 at 2:07 PM, George P. Stathis <gstathis@traackr.com>wrote:
>> On Thu, Apr 21, 2011 at 1:56 PM, Jean-Daniel Cryans <jdcryans@apache.org>wrote:
>>> On Thu, Apr 21, 2011 at 10:49 AM, George P. Stathis
>>> <gstathis@traackr.com> wrote:
>>> > I gave the thread that name because that was the best way I could come
>>> up
>>> > with to describe the symptoms. We still have the problem, it just may
>>> end up
>>> > be timestamp related after all.
>>> >
>>> No worries.
>>> > This does look similar, yes. I see there is no resolution currently.
>>> Well, if your use case is really to Put and Delete the same stuff
>>> right after the other, then yeah you will need a time resolution that
>>> more precise than milliseconds. Or you pass your own timestamps by
>>> doing the first puts are current time, then delete at current time +1,
>>> then put again if you want at current time +2, etc.
>> Looking at HBASE-2256, seems that it has been around for a while. We were
>> not seeing that issue when we were running on 0.20.6 and 0.89. The unit
>> tests that are failing have been in place since then. So I'm actually less
>> hopeful now. Still, I'll check the clocks on EC2.
>>> >
>>> > We have also noticed this problem in our local systems (laptops) but
>>> > actually much less frequently. I'll check the EC2 dates as soon as AWS
>>> > recovers (http://twitter.com/#!/search/%23aws). Our dev setup is
>>> currently
>>> > hosed...
>>> Heh :P
>>> J-D

View raw message