On Wed, Jan 22, 2014 at 11:35 AM, John Watson wrote:
> I thought PrintFLSStatistics was necessary for determining heap
> fragmentation? Or is it possible to see that without it as well?
>
I've found that easier parsing is more important than tracking indicators
of fragmentation.
Perm-Gen stays
I don't recommend PrintFLSStatistics=1, it makes the gc logs hard to
mechanically parse. Because of that, I can't easily tell whether you're in
the same situation we found. But just in case, try setting
+CMSClassUnloadingEnabled. There's an issue related to JMX in DSE that
prevents effective old
>
> Well from what I see in system.log it does not appear that GC aligns with
> this delay.
>
Though it does seem like quite a few GCs take place. Here is my system.log
> around the time of the delay:
>
It does sound like a lot of CMS runs - you'd like most of your garbage to
be collected in new s
I'd suggest setting some cassandra jvm parameters so that you can analyze a
heap dump and peek through the gc logs. That'll give you some clues e.g.
if the memory problem is growing steadily or suddenly, and clues from a
peek at which object are using the memory.
-XX:+HeapDumpOnOutOfMemoryError
Hi Rob, thanks for the refresher, and the the issue link (fixed today too-
thanks Sylvain!).
Cheers,
Lee
On Wed, Dec 18, 2013 at 10:47 AM, Robert Coli wrote:
> On Wed, Dec 18, 2013 at 9:26 AM, Lee Mighdoll wrote:
>
>> What's the current cassandra 2.0 advice on sizing for wi
I think the recommendation once upon a time was to keep wide storage engine
internal rows from growing too large. e.g. for time series, it was
recommended to partition samples by day or by hour to keep the size
manageable.
What's the current cassandra 2.0 advice on sizing for wide storage engine
