Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> Bulk loading job failed when one region server went down in the cluster

Copy link to this message
Re: Bulk loading job failed when one region server went down in the cluster

Do you know what happens when you have an airplane that has too heavy a cargo when it tries to take off?
You run out of runway and you crash and burn.

Looking at your post, why are you starting 8 map processes on each slave? That's tunable and you clearly do not have enough memory in each VM to support 8 slots on a node.
Here you swap, you swap you cause HBase to crash and burn.

3.2GB of memory means that no more than 1 slot per slave and even then... you're going to be very tight. Not to mention that you will need to loosen up on your timings since its all virtual and you have way too much i/o per drive going on.
My suggestion is that you go back and tune your system before thinking about running anything.



On Aug 13, 2012, at 2:11 PM, anil gupta <[EMAIL PROTECTED]> wrote:

> Hi Guys,
> Sorry for not mentioning the version I am currently running. My current
> version is HBase 0.92.1(cdh4) and running Hadoop2.0.0-Alpha with YARN for
> MR. My original post was for HBase0.92. Here are some more details of my
> current setup:
> I am running a 8 slave, 4 admin node cluster on CentOS6.0 VM's installed on
> VMware Hyprevisor 5.0. Each of my VM is having 3.2 GB of memory and 500
> HDFS space.
> I use this cluster for POC(Proof of Concepts). I am not looking for any
> performance benchmarking from this set-up. Due to some major bugs in YARN i
> am unable to make work in a proper way in memory less than 4GB. I am
> already having discussion regarding them on Hadoop Mailing List.
> Here is the log of failed mapper: http://pastebin.com/f83xE2wv
> The problem is that when i start a Bulk loading job in YARN, 8 Map
> processes start on each slave and then all of my slaves are hammered badly
> due to this. Since the slaves are getting hammered badly then RegionServer
> gets lease expired or YourAreDeadExpcetion. Here is the log of RS which
> caused the job to fail: http://pastebin.com/9ZQx0DtD
> I am aware that this is happening due to underperforming hardware(Two
> slaves are using one 7200 rpm Hard Drive in my setup) and some major bugs
> regarding running YARN in less than 4 GB memory. My only concern is the
> failure of entire MR job and its fault tolerance to RS failures. I am not
> really concerned about RS failure since HBase is fault tolerant.
> Please let me know if you need anything else.
> Thanks,
> Anil
> On Mon, Aug 13, 2012 at 6:58 AM, Michael Segel <[EMAIL PROTECTED]>wrote:
>> Yes, it can.
>> You can see RS failure causing a cascading RS failure. Of course YMMV and
>> it depends on which version you are running.
>> OP is on CHD3u2 which still had some issues. CDH3u4 is the latest and he
>> should upgrade.
>> (Or go to CHD4...)
>> HTH
>> -Mike
>> On Aug 13, 2012, at 8:51 AM, Kevin O'dell <[EMAIL PROTECTED]>
>> wrote:
>>> Anil,
>>> Do you have root cause on the RS failure?  I have never heard of one RS
>>> failure causing a whole job to fail.
>>> On Tue, Aug 7, 2012 at 1:59 PM, anil gupta <[EMAIL PROTECTED]>
>> wrote:
>>>> Hi HBase Folks,
>>>> I ran the bulk loader yesterday night to load data in a table. During
>> the
>>>> bulk loading job one of the region server crashed and the entire job
>>>> failed. It takes around 2.5 hours for this job to finish and the job
>> failed
>>>> when it was at around 50% complete. After the failure that table was
>> also
>>>> corrupted in HBase. My cluster has 8 region servers.
>>>> Is bulk loading not fault tolerant to failure of region servers?
>>>> I am using this old email chain because at that time my question went
>>>> unanswered. Please share your views.
>>>> Thanks,
>>>> Anil Gupta
>>>> On Tue, Apr 3, 2012 at 9:12 AM, anil gupta <[EMAIL PROTECTED]>
>> wrote:
>>>>> Hi Kevin,
>>>>> I am not really concerned about the RegionServer going down as the same
>>>>> thing can happen when deployed in production. Although, in production