You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Yang <te...@gmail.com> on 2011/09/29 20:14:37 UTC
StorageService.requestGC() ?
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]
Re: StorageService.requestGC() ?
Posted by Jonathan Ellis <jb...@gmail.com>.
right. path == null means "Cassandra is out of disk space."
On Thu, Sep 29, 2011 at 5:06 PM, Yang <te...@gmail.com> wrote:
> I am using mmap:
>
> INFO [main] 2011-09-29 21:35:21,458 DatabaseDescriptor.java (line
> 177) DiskAccessMode is mmap, indexAccessMode is mmap
>
>
>
> I think the cleanerMethod must be OK now,
>
> so the condition for GC
>
> if (path == null
> && (DatabaseDescriptor.getDiskAccessMode() ==
> Config.DiskAccessMode.mmap || DatabaseDescriptor.getIndexAccessMode()
> == Config.DiskAccessMode.mmap)
> && !MmappedSegmentedFile.isCleanerAvailable())
> {
>
>
> has to be triggered by path==null,
>
> I have put in more logging to debug it
>
>
>
> On Thu, Sep 29, 2011 at 2:42 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>> you're not using mmap i/o mode?
>>
>> On Thu, Sep 29, 2011 at 2:21 PM, Yang <te...@gmail.com> 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 <te...@gmail.com> 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 <jb...@gmail.com> 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 <te...@gmail.com> 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
>>
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: StorageService.requestGC() ?
Posted by Yang <te...@gmail.com>.
I am using mmap:
INFO [main] 2011-09-29 21:35:21,458 DatabaseDescriptor.java (line
177) DiskAccessMode is mmap, indexAccessMode is mmap
I think the cleanerMethod must be OK now,
so the condition for GC
if (path == null
&& (DatabaseDescriptor.getDiskAccessMode() ==
Config.DiskAccessMode.mmap || DatabaseDescriptor.getIndexAccessMode()
== Config.DiskAccessMode.mmap)
&& !MmappedSegmentedFile.isCleanerAvailable())
{
has to be triggered by path==null,
I have put in more logging to debug it
On Thu, Sep 29, 2011 at 2:42 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> you're not using mmap i/o mode?
>
> On Thu, Sep 29, 2011 at 2:21 PM, Yang <te...@gmail.com> 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 <te...@gmail.com> 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 <jb...@gmail.com> 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 <te...@gmail.com> 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
>
Re: StorageService.requestGC() ?
Posted by Jonathan Ellis <jb...@gmail.com>.
you're not using mmap i/o mode?
On Thu, Sep 29, 2011 at 2:21 PM, Yang <te...@gmail.com> 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 <te...@gmail.com> 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 <jb...@gmail.com> 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 <te...@gmail.com> 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
Re: StorageService.requestGC() ?
Posted by Yang <te...@gmail.com>.
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 <te...@gmail.com> 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 <jb...@gmail.com> 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 <te...@gmail.com> 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
>>
>
Re: StorageService.requestGC() ?
Posted by Yang <te...@gmail.com>.
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 <jb...@gmail.com> 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 <te...@gmail.com> 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
>
Re: StorageService.requestGC() ?
Posted by Jonathan Ellis <jb...@gmail.com>.
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 <te...@gmail.com> 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