Thanks guys. I've upgraded to 2.2.5, and the problem is gone.
Tom
On Wed, Mar 9, 2016 at 10:47 PM, Robert Coli wrote:
> On Mon, Mar 7, 2016 at 1:25 PM, Nate McCall
> wrote:
>
>>
>>> Rob, can you remember which bug/jira this was? I have not been able to
>>> find it.
>>> I'm using 2.1.9.
>>>
>>
On Mon, Mar 7, 2016 at 1:25 PM, Nate McCall wrote:
>
>> Rob, can you remember which bug/jira this was? I have not been able to
>> find it.
>> I'm using 2.1.9.
>>
>
> https://issues.apache.org/jira/browse/CASSANDRA-7953
>
> Rob may have a different one, but I've something similar from this issue.
>
>
> Rob, can you remember which bug/jira this was? I have not been able to
> find it.
> I'm using 2.1.9.
>
>
https://issues.apache.org/jira/browse/CASSANDRA-7953
Rob may have a different one, but I've something similar from this issue.
Fixed in 2.1.12.
--
-
Nate McCall
Austin,
Hi Bryan,
> Do you use any collections on this column family? We've had issues in the
> past with unexpectedly large partitions reported on data models with
> collections, which can also generate tons of tombstones on UPDATE (
> https://issues.apache.org/jira/browse/CASSANDRA-10547)
>
I've been
Hi Rob,
The reason I didn't dump the table with sstable2json is that I didn't think
of it ;) I just used it, and it looks very much like the "avalanche of
tombstones" bug you are describing!
I took one of the three sstables containing the key, and it resulted in a
4.75 million-line json file, of
Hi Tom,
Do you use any collections on this column family? We've had issues in the
past with unexpectedly large partitions reported on data models with
collections, which can also generate tons of tombstones on UPDATE (
https://issues.apache.org/jira/browse/CASSANDRA-10547)
--Bryan
On Mon, Mar 7
On Sat, Mar 5, 2016 at 9:16 AM, Tom van den Berge wrote:
> I don't think compression can be the cause of the difference, because of
> two reasons:
>
Your two reasons seem legitimate.
Though you say you do not frequently do DELETE and so it shouldn't be due
to tombstones, there are semi-recent v
No, data is hardly ever deleted from this table. The cfstats conform this.
The data is also nog reinserted.
Op 5 mrt. 2016 6:20 PM schreef "DuyHai Doan" :
> Maybe tombstones ? Do you issue a lot of DELETE statements ? Or do you
> re-insert in the same partition with different TTL values ?
>
> On S
Maybe tombstones ? Do you issue a lot of DELETE statements ? Or do you
re-insert in the same partition with different TTL values ?
On Sat, Mar 5, 2016 at 7:16 PM, Tom van den Berge wrote:
> I don't think compression can be the cause of the difference, because of
> two reasons:
>
> 1) The partiti
I don't think compression can be the cause of the difference, because of
two reasons:
1) The partition size I calculated myself (3 MB) is the uncompressed size,
and so is the reported size (2.3 GB)
2) The difference is simply way too big to be explained by compression,
even if the calculated size
On Fri, Mar 4, 2016 at 5:56 AM, Tom van den Berge wrote:
> Compacting large partition
> drillster/subscriberstats:rqtPewK-1chi0JSO595u-Q (1,470,058,292 bytes)
>
> This means that this single partition is about 1.4GB large. This is much
> larger that it can possibly be, because of two reasons:
>
Hi,
I'm seeing warnings in my logs about compacting large partitions, e.g.:
Compacting large partition
drillster/subscriberstats:rqtPewK-1chi0JSO595u-Q (1,470,058,292 bytes)
This means that this single partition is about 1.4GB large. This is much
larger that it can possibly be, because of two r
12 matches
Mail list logo
