Re: Bizarre side-effect of increasing read concurrency

2011-04-03 Thread Peter Schuller
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

Re: Bizarre side-effect of increasing read concurrency

2011-04-02 Thread Peter Schuller
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

Re: Bizarre side-effect of increasing read concurrency

2011-04-02 Thread Peter Schuller
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 maximum

Re: Bizarre side-effect of increasing read concurrency

2011-04-02 Thread Jason Harvey
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 peter.schul...@infidyne.com wrote: Previously, mark-and-sweep would run around 5.5GB, and would cut heap

Bizarre side-effect of increasing read concurrency

2011-04-01 Thread Jason Harvey
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.

Re: Bizarre side-effect of increasing read concurrency

2011-04-01 Thread Jason Harvey
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 alie...@gmail.com wrote:

Re: Bizarre side-effect of increasing read concurrency

2011-04-01 Thread Edward Capriolo
On Fri, Apr 1, 2011 at 11:27 PM, Jason Harvey alie...@gmail.com 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

Re: Bizarre side-effect of increasing read concurrency

2011-04-01 Thread Jason Harvey
Ah, that would probably explain it. Thanks! On Apr 1, 8:49 pm, Edward Capriolo edlinuxg...@gmail.com wrote: On Fri, Apr 1, 2011 at 11:27 PM, Jason Harvey alie...@gmail.com wrote: On further analysis, it looks like this behavior occurs when a node is simply restarted. Is that normal behavior?