Hi, I found many simmilar lines in log: INFO [SlabPoolCleaner] 2015-02-24 12:28:19,557 ColumnFamilyStore.java:850 - Enqueuing flush of customer_events: 95299485 (5%) on-heap, 0 (0%) off-heap INFO [MemtableFlushWriter:1465] 2015-02-24 12:28:19,569 Memtable.java:339 - Writing Memtable-customer_events@2011805231(25791893 serialized bytes, 130225 ops, 5%/0% of on/off-heap limit) INFO [MemtableFlushWriter:1465] 2015-02-24 12:28:20,731 Memtable.java:378 - Completed flushing /grid/data04/cassandra/data/prem_maelstrom/customer_events-dbf0f26031ff11e4bb64b7d2603bc25a/prem_maelstrom-customer_events-ka-207535-Data.db (9551014 bytes) for commitlog position ReplayPosition(segmentId=1424694746404, position=418223)
Which means that somehow when memtable is around 100 MB (95299485) - 5%of heap it starts to be written on disk. During conversion to SSTable the compression is applied and result size is like 10% of original -> ~10MB(9551014). Am I right? The question of course are: 1) why so small memtables are flushed to disk if I configured commitlog_total_space_in_mb to 1024? 2) why this small SSTables are not compacted? The compaction process still takes bigger SSTables? Maybe I should change compaction strategy? On Thu, Feb 26, 2015 at 5:24 PM, Roland Etzenhammer < r.etzenham...@t-online.de> wrote: > Hi, > > 8GB Heap is a good value already - going above 8GB will often result in > noticeable gc pause times in java, but you can give 12G a try just to see > if that helps (and turn it back down again). You can add a "Heap Used" > graph in opscenter to get a quick overview of your heap state. > > Best regards, > Roland > > >
