Hi, Todd
Thx for replying in Japanese :-) lspci shows the following hardware.
$ lspci | grep Ether
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
> http://ark.intel.com/Product.asp
Hi, All
Thanks for the helpful comments!
Nice to see this happens rarely in other environments.
Actually I've changed the configuration not to run the task on the master node,
but the same problem happened.
So at first, upgrade the switch. Report again if the problem will be fixed.
Thanks
Kazuk
> I'm now using CDH3u0 at 16nodes cluster (hdp0-hdp15).
> The configuraiton is below.
>
> hdp0: zk + master + region + nn + dn + jt + tt
> hdp1: zk + master + region + snn + dn + tt
> hdp2: zk + region + dn + tt
> hdp3 to hdp15: region + dn + tt
>
>
I would also look at the memory configuration for
This is your problem. Sounds like a very deficient switch.
On Wed, Apr 20, 2011 at 11:41 AM, Kazuki Ohta wrote:
> The problem is that shuffle network transfer dominates the switch,
> and important zk packets are not transferred properly at that time.
>
hardware.
- Andy
> From: Kazuki Ohta
> Subject: massive zk expirations under heavy network load
> To: user@hbase.apache.org
> Cc: kazuki.o...@gmail.com
> Date: Wednesday, April 20, 2011, 11:41 AM
> Hi,
>
> I'm now using CDH3u0 at 16nodes cluster (hdp0-hdp15).
> The c
Hi,
I'm now using CDH3u0 at 16nodes cluster (hdp0-hdp15).
The configuraiton is below.
hdp0: zk + master + region + nn + dn + jt + tt
hdp1: zk + master + region + snn + dn + tt
hdp2: zk + region + dn + tt
hdp3 to hdp15: region + dn + tt
Usually, it works really well. But once the user throws MapR
