you're not using mmap i/o mode? On Thu, Sep 29, 2011 at 2:21 PM, Yang <[email protected]> wrote: > I see now : > > https://issues.apache.org/jira/browse/CASSANDRA-2521?focusedCommentId=13050396&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050396 > > > > but my logs doesn't show the error from > > MMappedSegmentedFile: > > public static void initCleaner() > { > try > { > cleanerMethod = > Class.forName("sun.nio.ch.DirectBuffer").getMethod("cleaner"); > } > catch (Exception e) > { > // Perhaps a non-sun-derived JVM - contributions welcome > logger.info("Cannot initialize un-mmaper. (Are you using > a non-SUN JVM?) Compacted data files will not be removed promptly. > Consider using a SUN JVM or using standard disk access mode"); > } > } > > > and indeed I'm using openJDK. I'll switch to sun jdk, but am still > curious why cleanerMethod is null in my case but I don't see the log > message > > > On Thu, Sep 29, 2011 at 12:03 PM, Yang <[email protected]> wrote: >> I thought the need for GC was based on the code that sstables >> deletions are tracked through weak/phantom references. >> now I see that sstable is deleted in SStableReader.ReleaseReferences() >> ---> SegmentedFile.cleanup(), >> if this is true, is GC still necessary? >> >> Thanks >> Yang >> >> On Thu, Sep 29, 2011 at 11:50 AM, Jonathan Ellis <[email protected]> wrote: >>> As the comment says, >>> // retry after GCing to force unmap of compacted SSTables >>> so they can be deleted >>> >>> See also http://wiki.apache.org/cassandra/MemtableSSTable >>> >>> Note that this has changed in 1.0: >>> https://issues.apache.org/jira/browse/CASSANDRA-2521 >>> >>> On Thu, Sep 29, 2011 at 1:14 PM, Yang <[email protected]> wrote: >>>> Table.getDataFileLocation() calls StorageService.requestGC(), which >>>> calls System.gc() >>>> >>>> I think I saw one GC in my log due to this code, and it caused a JVM >>>> freeze for 14 seconds. >>>> why do we need to call explicit GC ? >>>> >>>> thanks >>>> Yang >>>> >>>> >>>> >>>> [Times: user=2.81 sys=0.00, real=0.46 secs] >>>> 3472.943: [GC 3472.943: [ParNew: 21339139K->326984K(23592960K), >>>> 0.4742050 secs] 30764101K->10032251K(49807360K), 0.4743710 secs] >>>> [Times: user=2.91 sys=0.01, real=0.47 secs] >>>> 3519.043: [GC 3519.043: [ParNew: 21298504K->386099K(23592960K), >>>> 0.5201430 secs] 31003771K->10363088K(49807360K), 0.5203120 secs] >>>> [Times: user=3.15 sys=0.03, real=0.52 secs] >>>> 3560.277: [GC 3560.278: [ParNew: 21357619K->434850K(23592960K), >>>> 0.4693880 secs] 31334608K->10676370K(49807360K), 0.4695450 secs] >>>> [Times: user=2.92 sys=0.00, real=0.47 secs] >>>> 3601.343: [Full GC (System) 3601.343: [CMS: >>>> 10241519K->3496676K(26214400K), 14.6823750 secs] >>>> 28763882K->3496676K(49807360K), [CMS Perm : 27683K->27623K(27776K)], >>>> 14.6900120 secs] [Times: user=14.73 sys=0.00, real=14.69 secs] >>>> 3665.223: [GC 3665.224: [ParNew: 20971520K->361802K(23592960K), >>>> 0.2379040 secs] 24468196K->3858479K(49807360K), 0.2380660 secs] >>>> [Times: user=1.57 sys=0.01, real=0.23 secs] >>>> 3704.967: [GC 3704.968: [ParNew: 21333322K->359503K(23592960K), >>>> 0.4433910 secs] 24829999K->4173314K(49807360K), 0.4435500 secs] >>>> [Times: user=2.72 sys=0.02, real=0.44 secs] >>>> 3801.962: [GC 3801.962: [ParNew: 21331023K->388609K(23592960K), >>>> 0.5236180 secs] 25144834K->4479343K(49807360K), 0.5238240 secs] >>>> [Times: user=3.42 sys=0.00, real=0.53 secs] >>>> >>> >>> >>> >>> -- >>> Jonathan Ellis >>> Project Chair, Apache Cassandra >>> co-founder of DataStax, the source for professional Cassandra support >>> http://www.datastax.com >>> >> >
-- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
