hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George P. Stathis" <gstat...@traackr.com>
Subject Re: Latency related configs for 0.90
Date Thu, 28 Apr 2011 00:51:59 GMT
On Wed, Apr 27, 2011 at 8:13 PM, Jean-Daniel Cryans <jdcryans@apache.org>wrote:

> 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.
>

No, I did indeed restart hbase as the instructions suggest we do after the
script is executed.


>
> 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
>

The setting were there in the legacy dev hbase instance we have. It was set
to 16K and the script set it to 64K. So it seems this was expected. Where I
don't understand is the effect the script had on a brand new 0.90 install.
Before we ran the script, the setting was not there. After we ran it, it was
there with the 64K value.

For both legacy and new instances, running the script and re-starting hbase
solved our issue.


>
> Hope we can resolve this mystery.
>
> J-D
>
> 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
> >>>
> >>
> >>
> >
>

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