Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates
 209.85.215.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAnh3_9-4xfv03W5+1mM9J8v6-__D41DDvxd0TBJWZZeMEFaQg@mail.gmail.com>
References: 
 <466831341-1317401129-cardhu_decombobulator_blackberry.rim.net-657950712-@b18.c2.bise3.blackberry>
 <CAKrGPjybfUjUxsJx6bfBmo_xRDR7SYMS6ToR-0zjwVgCm+16Rw@mail.gmail.com>
 <CAAnh3_9-4xfv03W5+1mM9J8v6-__D41DDvxd0TBJWZZeMEFaQg@mail.gmail.com>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Fri, 30 Sep 2011 12:17:25 -0500
Message-ID: 
 <CALdd-zjXFPAssQu5nsdtuA-up-C5iXxpYPkTumyqdpcRMNSBYg@mail.gmail.com>
Subject: Re: release mmap memory through jconsole?
To: user@cassandra.apache.org
Content-Type: text/plain; charset=Big5
Content-Transfer-Encoding: quoted-printable

I think we found why you're seeing lots of young gen-based GC pauses... :)

2011/9/30 Yang <teddyyyy123@gmail.com>:
> why?
>
> I thought bigger young gen would allow more objects to die (become
> non-reachable) before  minor collection, so the minor collection cost
> is low. particularly it would allow you to merge more updates and not
> consume memory (since old objects are released on GC)
>
> bigger old gen would allow you to accumulate more rows into your
> memtable, so you can avoid
> later compaction cost.
>
>
> if not giving it to heap, then it's a choice between os buffer and
> cassandra row cache. I think row cache is definitely better since you
> avoid the cost of serializing/deserializing; well this is assuming
> that your access pattern is random though, otherwise OS cache has the
> benefit of spacial locality (it loads blocks at once instead of a
> single row).
>
> thanks
> Yang
>
> 2011/9/30 Norman Maurer <norman.maurer@googlemail.com>:
>> I would also not use such a big heap. I think most people will tell
>> you that 12G -16G is max to use.
>>
>> Bye,
>> Norman
>>
>> 2011/9/30 Yi Yang <i@iyyang.com>:
>>> It is meaningless to release such memory. The counting includes the dat=
a you reached in the SSTable. Those data locates on your hard drive. So it =
is not the RAM spaces you have actually used.
>>>
>>> -Y.
>>> ------Original Message------
>>> From: Yang
>>> To: user@cassandra.apache.org
>>> ReplyTo: user@cassandra.apache.org
>>> Subject: release mmap memory through jconsole?
>>> Sent: Oct 1, 2011 12:40 AM
>>>
>>> I gave an -Xmx50G to my Cassandra java processs, now "top" shows its
>>> virtual memory address space is 82G, is there
>>> a way to release that memory through JMX ?
>>>
>>> Thanks
>>> Yang
>>>
>>> =B1q=A7=DA=AA=BA BlackBerry(R) =B5L=BDu=B8=CB=B8m
>>
>


--=20
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com