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* > >
