cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-208) OOM intermittently during compaction
Date Fri, 05 Jun 2009 01:10:07 GMT


Jonathan Ellis commented on CASSANDRA-208:

1. empty memtables are not flushed, so there will be at least one key, and the first key will
always be in indexEntries since 0 % interval == 0 for any interval.  lots of the tests have
only one row.  I don't think there is a problem here.

2. ok

3. Hmm, if you have columns B C and D in a row, and you do a slice_from starting with A, don't
you want B C D to be returned?  getNearestPosition will start the scan at B, but vanilla getPosition
will return -1 if there is not an exact match.

> OOM intermittently during compaction
> ------------------------------------
>                 Key: CASSANDRA-208
>                 URL:
>             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
> 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.

View raw message