No we don't. Sent from my iPhone
> On Apr 16, 2014, at 9:21 AM, Mark Reddy <mark.re...@boxever.com> wrote: > > Do you delete and/or set TTLs on your data? > > >> On Wed, Apr 16, 2014 at 2:14 PM, Ruchir Jha <ruchir....@gmail.com> wrote: >> Hi, >> >> I am trying to investigate ParNew promotion failures happening routinely in >> production. As part of this exercise, I enabled >> -XX:PrintHistogramBeforeFullGC and saw the following output. As you can see >> there are a ton of Columns, ExpiringColumns and DeletedColumns before GC ran >> and these numbers go down significantly right after GC. Why are there so >> many expiring and deleted columns? >> >> Before GC: >> >> num #instances #bytes class name >> ---------------------------------------------- >> 1: 113539896 5449915008 java.nio.HeapByteBuffer >> 2: 15979061 2681431488 [B >> 3: 36364545 1745498160 >> edu.stanford.ppl.concurrent.SnapTreeMap$Node >> 4: 23583282 754665024 org.apache.cassandra.db.Column >> 5: 8745428 209890272 >> java.util.concurrent.ConcurrentSkipListMap$Node >> 6: 5062619 202504760 org.apache.cassandra.db.ExpiringColumn >> 7: 45261 198998216 [I >> 8: 1801535 172947360 >> edu.stanford.ppl.concurrent.CopyOnWriteManager$COWEpoch >> 9: 1473677 169570040 [J >> 10: 4713304 113119296 java.lang.Double >> 11: 3246729 103895328 org.apache.cassandra.db.DeletedColumn >> >> After GC: >> num #instances #bytes class name >> ---------------------------------------------- >> 1: 11807204 1505962728 [B >> 2: 12525536 601225728 java.nio.HeapByteBuffer >> 3: 8839073 424275504 edu.stanford.ppl.concurrent.SnapTreeMap$Node >> 4: 8194496 262223872 org.apache.cassandra.db.Column >> cache.KeyCacheKey >> 17: 432119 17284760 org.apache.cassandra.db.ExpiringColumn >> 21: 351096 11235072 org.apache.cassandra.db.DeletedColumn >
