cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-208) OOM intermittently during compaction
Date Wed, 10 Jun 2009 13:12:07 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718068#action_12718068
] 

Hudson commented on CASSANDRA-208:
----------------------------------

Integrated in Cassandra #104 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/104/])
    apply rows atomically, rather than one-column-at-a-time.  this avoids exposing the bug
in time-sorted
columns discussed in #223.
patch by jbellis; reviewed by Jun Rao for 
split sstable into data, index, and bloom filter files.  this allows us to avoid saving up
index chunks
in memory until the sstable data is completely written, while still allowing fast scanning
of the index
on startup.  it also simplifies the sstable/sequencefile code considerably.
patch by jbellis; reviewed by Jun Rao for  


> OOM intermittently during compaction
> ------------------------------------
>
>                 Key: CASSANDRA-208
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-208
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: arch: x86_64
> os: Linux version 2.6.18-92.1.22.el5 
> java: nio2-ea-bin-b99-linux-x64-05_feb_2009
>            Reporter: Jiansheng Huang
>            Assignee: Jonathan Ellis
>            Priority: Critical
>             Fix For: 0.4
>
>         Attachments: 0001-CASSANDRA-208-cleanup.txt, 0002-r-m-touch.txt, 0003-split-sstable-into-data-index-and-bloom-filter-files.txt,
0004-fix-ColumnReader-add-tests.patch, 0005-fix-test-order-dependent-failures.patch, 208-2.patch,
208-3.patch, 208.patch
>
>
> jvm crashes intermittently during compaction. Our test data set is not that big, less
than 10 GB.
> When jvm is about to crash, we see that it consumes a lot of memory (exceeding the max
heap size).
> The excessive memory usage during compaction is caused by the maintenance of blockIndexes_
in SSTable. this blockIndexes_ was only introduced to the apache version.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message