> > Also, note that lack of saw-toothing is not a goal in and of itself > and may even be bad. For example, with respect to the young generation > the situation is essentially: > > (1) The larger the young generation, the more significant the saw-tooth. > (2) The larger the young generation, the more efficient the GC (if the > application behaves according to the weak generational hypothesis - > google it if you want a ref) because less data is promoted to old gen > and because the overhead of stop-the-world is lessened. > (3) The larger the young generation, the longer the pause times to do > collections of the young generation. > In this regard, what I personally miss in Mikios - however nice - analysis, is what are the effects on the application stop times due to any garbage collection runs for the cases tested. In most cases, I prefer having low pauses due to any garbage collection runs and don't care too much about the shape of the memory usage, and I guess, that's the reason why the low pause collector is used by default for running cassandra. For myself, I have mixed feelings regarding the low pause collector, because I found it difficult to find good young generation sizings, which are suitable to different load patterns. Therefor I mostly prefer the throughput collector, which adaptively sizes the young generation, doing a good job to avoiding that too much data goes to the tenured generation. I would be interested in, what are the differences concerning the stop times between the different GC variants, when running cassandra. Is it really much better to use the low pause collector in regard to get stabile response times, even if I use XX:+UseParallelOldGC and XX:MaxGCPauseMillis=nnn flags? Any experiences with this?
Regards, Carsten
