cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Talbot (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5182) Deletable rows are sometimes not removed during compaction
Date Thu, 24 Jan 2013 00:27:12 GMT


Bryan Talbot commented on CASSANDRA-5182:

Using the test program attached, I've reproduce the problem using 1.1.9 and then upgraded
that cluster (1 node on laptop) to 1.2.0.  The problem remains with the load and sstable count

However, when I run the test program on a fresh 1.2.0 cluster the problem does not come up.
 My process to reproduce on upgrade is:

install fresh 1.1.9
run test to get 500 MB of data (20-30 mins)
drain and shutdown 1.1.9
start 1.2.0
run nodetool upgradesstables
run test and watch load grow to 2.5 GB while away at lunch

When running the test program on a fresh 1.2.0 installation, the load tops out at about 200
MB and 90 or so SSTables which is what is desired.

> Deletable rows are sometimes not removed during compaction
> ----------------------------------------------------------
>                 Key: CASSANDRA-5182
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.5
>            Reporter: Binh Van Nguyen
>            Assignee: Yuki Morishita
>             Fix For: 1.1.10, 1.2.1
>         Attachments: 5182-1.1.txt, test_ttl.tar.gz
> Our use case is write heavy and read seldom.  To optimize the space used, we've set the
bloom_filter_fp_ratio=1.0  That along with the fact that each row is only written to one time
and that there are more than 20 SSTables keeps the rows from ever being compacted. Here is
the code:
> We hit this conner case and because of this C* keeps consuming more and more space on
disk while it should not.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message