Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of maarten@vrijheid.net designates
 69.64.155.201 as permitted sender)
Message-Id: <143328C7-D0B0-4F12-9FF1-8AC370E1BBF3@vrijheid.net>
From: Maarten Koopmans <maarten@vrijheid.net>
To: "zookeeper-user@hadoop.apache.org" <zookeeper-user@hadoop.apache.org>
In-Reply-To: <AANLkTi=OG+edfM=Pp=1AWUap_9gjXjby2KLH4KamSCte@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (iPad Mail 7B500)
Subject: Re: Zookeeper on 60+Gb mem
Date: Tue, 5 Oct 2010 23:59:22 +0200
References: <E220557B-FA2B-4064-B78F-986FAEB652C2@vrijheid.net>
 <C8D0B928.4385F%mahadev@yahoo-inc.com>
 <AANLkTi=U0Z06zcnOC=JhvJpbfwtHaQ1M1Tb9x2-p00RO@mail.gmail.com>
 <4CAB78D3.4020507@yahoo-inc.com>
 <CD0C5B1B-8494-42C4-9C73-AE2359D60E7E@vrijheid.net>
 <AANLkTi=OG+edfM=Pp=1AWUap_9gjXjby2KLH4KamSCte@mail.gmail.com>

Yup, and that's ironic, isn't it? The gc tuning is so specialistic, as =
is the profiling, that automated memory management (to me) hasn't =
brought what I hoped it would. I've had some conversations about this =
topic a few years back with a well respected OS designer, and his point =
is that we (humans) can trace back almost all problems because we're =
adding complexity, in stead of reducing it.

Sorry for the slight rant.... Anyway, it's one of the things I like =
about zookeeper (and, e.g. voldemort): it makes a hard thing doable.

--Maarten


Op 5 okt. 2010 om 23:27 heeft Patrick Hunt <phunt@apache.org> het =
volgende geschreven:

> Tuning GC is going to be critical, otw all the sessions will timeout =
(and
> potentially expire) during GC pauses.
>=20
> Patrick
>=20
> On Tue, Oct 5, 2010 at 1:18 PM, Maarten Koopmans =
<maarten@vrijheid.net>wrote:
>=20
>> Yes, and syncing after a crash will be interesting as well. Off note; =
I am
>> running it with a 6GB heap now, but it's not filled yet. I do have =
smoke
>> tests thoug, so maybe I'll give it a try.
>>=20
>>=20
>>=20
>> Op 5 okt. 2010 om 21:13 heeft Benjamin Reed <breed@yahoo-inc.com> het
>> volgende geschreven:
>>=20
>>>=20
>>> you will need to time how long it takes to read all that state back =
in
>> and adjust the initTime accordingly. it will probably take a while to =
pull
>> all that data into memory.
>>>=20
>>> ben
>>>=20
>>> On 10/05/2010 11:36 AM, Avinash Lakshman wrote:
>>>> I have run it over 5 GB of heap with over 10M znodes. We will =
definitely
>> run
>>>> it with over 64 GB of heap. Technically I do not see any =
limitiation.
>>>> However I will the experts chime in.
>>>>=20
>>>> Avinash
>>>>=20
>>>> On Tue, Oct 5, 2010 at 11:14 AM, Mahadev =
Konar<mahadev@yahoo-inc.com
>>> wrote:
>>>>=20
>>>>> Hi Maarteen,
>>>>> I definitely know of a group which uses around 3GB of memory heap =
for
>>>>> zookeeper but never heard of someone with such huge requirements. =
I
>> would
>>>>> say it definitely would be a learning experience with such high =
memory
>>>>> which
>>>>> I definitely think would be very very useful for others in the
>> community as
>>>>> well.
>>>>>=20
>>>>> Thanks
>>>>> mahadev
>>>>>=20
>>>>>=20
>>>>> On 10/5/10 11:03 AM, "Maarten Koopmans"<maarten@vrijheid.net>  =
wrote:
>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> I just wondered: has anybody ever ran zookeeper "to the max" on a =
68GB
>>>>>> quadruple extra large high memory EC2 instance? With, say, 60GB
>> allocated
>>>>> or
>>>>>> so?
>>>>>>=20
>>>>>> Because EC2 with EBS is a nice way to grow your zookeeper cluster
>> (data
>>>>> on the
>>>>>> ebs columes, upgrade as your memory utilization grows....)  - I =
just
>>>>> wonder
>>>>>> what the limits are there, or if I am foing where angels fear to
>> tread...
>>>>>>=20
>>>>>> --Maarten
>>>>>>=20
>>>>>=20
>>>=20
>>>=20
>>=20