Hey Garo,
I see you are using 2.2.x. Do you have compression enabled on commit logs by
any chance? If so, try to disable it and see if that helps.
Right after migrating from 2.1.x to 2.2.x, I remember having the behavior you
described with 10k SAS disks when commit log compression was enabled
On Wed, Jul 27, 2016 at 10:56 PM, Jacob Willoughby
wrote:
> I have been investigating cassandra to store small objects as a trivial
> replacement for s3. GET/PUT/DELETE are all easy, but LIST is what is
> tripping me up.
>
>
> S3 does a hierarchical list that kinda simulates traversing folders.
>
thanks a lot Alain. That was really great info.
The issues here was that tombstones were not in the SSTable, but rather in
the Memtable. We had to a nodetool flush, and run a nodetool compact to get
rid of the tombstones, a million of them. The size of the largest SSTable
was actually 48MB.
This
Hey C*,
During startup of a Cassandra 2.2.7 node, some part of the process fails.
Here's a snippet of logs with the stack trace
TRACE [main] 2016-07-28 19:06:25,381 SliceQueryFilter.java:269 - collecting 6
of 2147483647:
custom_table:ep_str:component_index:false:4@1441163636178000TRACE [main]
Tombstones will not get removed even after gc_grace if bloom filters
indicate that there is overlapping data with the tombstone's partition in a
different sstable. This is because compaction can't be certain that the
tombstone doesn't overlap data in that other table. If you're writing to
one end
Hi,
@Eric
Large range tombstones can occupy just a few bytes but can occlude millions
> of records, and have the corresponding performance impact on reads. It's
> really not the size of the tombstone on disk that matters, but the number
> of records it occludes.
Sai was describing a timeout, n
From: Eric Evans
Sent: Thursday, July 28, 2016 9:19 AM
To: user@cassandra.apache.org
Subject: Re: Listing Keys Hierarchically Using a Prefix and Delimiter
> Perhaps you could just store the objects as a simple key-value
> representation (like your "stuff"
