On Fri, Aug 27, 2010 at 6:49 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > I supsect something else is making the difference for ecapriolo. The > documentation says, > > The incremental mode is meant to lessen the impact of long concurrent > phases by periodically stopping the concurrent phase to yield back the > processor to the application. [Remember, "concurrent" means "not > blocking other threads" in this context.] This mode (referred to here > as “i-cms”) divides the work done by concurrently by the collector > into small chunks of time which are scheduled between young generation > collections. This feature is useful when applications that need the > low pause times provided by the concurrent collector are run on > machines with small numbers of processors (e.g., 1 or 2) > > There's also close to a dozen tuning options for i-cms. It seems a > little fragile to me. > > On Fri, Aug 27, 2010 at 4:53 PM, Benjamin Black <b...@b3k.us> wrote: >> ecapriolo's testing seemed to indicate it _did_ change the behavior. >> wonder what the difference is? >> >> On Fri, Aug 27, 2010 at 6:23 AM, Mikio Braun <mi...@cs.tu-berlin.de> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Dear all, >>> >>> thanks for your comments, and I'm glad that you found my post helpful. >>> >>> Concerning the incremental CMS, I've recently updated my post and added >>> the experiments repeated on one of our cluster nodes, and for some >>> reason incremental CMS doesn't look that different anymore. So I guess >>> it's ok to stick with the non-incremental CMS for now. >>> >>> - -M >>> >>> On 08/27/2010 09:12 AM, Peter Schuller wrote: >>>>> Whether or not this is likely to happen with Cassandra I don't know. I >>>>> don't know much about the incremental duty cycles are scheduled and it >>>>> may be the case that Cassandra is not even remotely close to having a >>>>> problem with incremental mode. >>>> >>>> I should further weaken my statement by pointing out that I never did >>>> any exhaustive tweaking to get around the problem (other than >>>> disabling incremental mode, since my primary goal has tended to be >>>> ensure low pause times and not so much even GC activity). It may be >>>> the case that even in stressful cases where it fails by default it is >>>> simply a matter of tweaking. >>>> >>>> So, I guess I should re-phrase: In terms of just turning on >>>> incremental mode without at least application specific tweaking (if >>>> not deployment specific testing), I would suggest caution. >>>> >>>> >>> >>> >>> - -- >>> Dr. Mikio Braun email: mi...@cs.tu-berlin.de >>> TU Berlin web: ml.cs.tu-berlin.de/~mikio >>> Franklinstr. 28/29 tel: +49 30 314 78627 >>> 10587 Berlin, Germany >>> >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAkx3vFUACgkQtnXKX8rQtgDUlgCfWb/euA2mgVJAWDY2tBSyAN+I >>> 604AoKVua1+5bYK2yF9CWwFQmLHDt0Fn >>> =CIal >>> -----END PGP SIGNATURE----- >>> >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com >
Before I applied these changes the young gen and the survivor space were very spiky. Now they both seem very low all the time. As you see from my screen shot, before these changes my JVM memory would make large saw tooths, now all three pools young, eden, perm seem smoother. I am worried that the cms descriptions talk about systems with 1-2 processor machines, being my system shows up at 16 processors after hyper threading. Is something else going on. :) I am not in a lab so I have many external factors. Being that it takes a long time to build up a row cache its hard to compare for hours. (On a side node I have started working on 'nodetool savecache' so hopefully I figure out a way to save the cache to an external file and recall it after start up. Seems like there could be edge cases where bring up a cache even from moments ago could be be, but will see)
