hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Flavio Pompermaier <pomperma...@okkam.it>
Subject Re: HBase cluster design
Date Thu, 15 May 2014 23:08:19 GMT
Thanks for the response. Actually I'm still trying to understand why some
of the regions of my Hbase goes down from time to time during my mapred job
if table updates occur because in the logs there's nothing interesting..The
updates usually happens in bursts of 10/100 sequential puts per seconds. Is
there any rule of thumb about those scenarios to avoid problems or some
fundamental tuning to check? I have a lot of ram (48g) and 24 processor per
server (for a total  of 4 servers) and I have not that much data (20g) so I
don't understand why the region servers goes down (usually after a couple
of mapred job).
However in general, speaking also with other people using Hbase, it seems
that is not very safe to run mapred jobs while updating the table..are we


On Wed, May 14, 2014 at 7:04 PM, Stack <stack@duboce.net> wrote:

> On Tue, May 13, 2014 at 3:14 AM, Flavio Pompermaier <pompermaier@okkam.it
> >wrote:
> > So just to summarize the result of this discussion..
> > do you confirm me that the last version of HBase should (in theory)
> support
> > mapreduce jobs on tables that in the meantime could be updated by
> external
> > processes (i.e. not by the mapred job)?
> > One of the answer about this was saying: "Poorly tuned HBase clusters can
> > fail easily under heavy load"..
> > Could you suggest me some tuning to avoid the crashing of HBase in such
> > situations?
> >
> Run less mappers/reducers.  Start with one only and move up from there.
>  Ditto for other processes updating hbase.
> You have monitoring going on on this cluster?  What is it telling you about
> the loadings?
> St.Ack

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