> My Xmx and Xms are both 7.5GB. However, I never see the heap usage
> reach past 5.5. Think it is still a good idea to increase the heap?
Not necessarily. I thought you had a max heap of 5.5, in which case a
live set of 4 gb after a completed cms pass seemed pretty high. Seems
more reasonable if
My Xmx and Xms are both 7.5GB. However, I never see the heap usage
reach past 5.5. Think it is still a good idea to increase the heap?
Thanks,
Jason
On Apr 2, 2:45 am, Peter Schuller wrote:
> > Previously, mark-and-sweep would run around 5.5GB, and would cut heap
> > usage to 4GB. Now, it still
> Previously, mark-and-sweep would run around 5.5GB, and would cut heap
> usage to 4GB. Now, it still runs at 5.5GB, but it shrinks all the way
> down to 2GB used. This behavior was consistent in every machine I
> increased read-concurrent on.
So each full CMS cycles brings it down to 4 on a maxim
> Java also enjoys using all the memory your allocate and the Garbage
> collection does not give it back unless it needs to.
This only explains why it never shrinks in top, not increased heap
usage (which is presumably the memtables/key/row caches already
mentioned).
--
/ Peter Schuller
Ah, that would probably explain it. Thanks!
On Apr 1, 8:49 pm, Edward Capriolo wrote:
> On Fri, Apr 1, 2011 at 11:27 PM, Jason Harvey wrote:
> > On further analysis, it looks like this behavior occurs when a node is
> > simply restarted. Is that normal behavior? If mark-and-sweep becomes
> > les
On Fri, Apr 1, 2011 at 11:27 PM, Jason Harvey wrote:
> On further analysis, it looks like this behavior occurs when a node is
> simply restarted. Is that normal behavior? If mark-and-sweep becomes
> less and less effective over time, does that suggest an issue with GC,
> or an issue with memory us
On further analysis, it looks like this behavior occurs when a node is
simply restarted. Is that normal behavior? If mark-and-sweep becomes
less and less effective over time, does that suggest an issue with GC,
or an issue with memory use?
On Apr 1, 8:21 pm, Jason Harvey wrote:
> After increasing
After increasing read concurrency from 8 to 64, GC mark-and-sweep was
suddenly able to reclaim much more memory than it previously did.
Previously, mark-and-sweep would run around 5.5GB, and would cut heap
usage to 4GB. Now, it still runs at 5.5GB, but it shrinks all the way
down to 2GB used. This
