On May 14, 2013, at 6:50 AM, aaron morton wrote:
>> Let's say we're seing some bug in C*, and SSTables doesn't get deleted
>> during compaction (which I guess is the only reason for this consumption of
>> diskspace).
>
> Just out of interest can you check the number of SSTables reported by
> Let's say we're seing some bug in C*, and SSTables doesn't get deleted during
> compaction (which I guess is the only reason for this consumption of
> diskspace).
Just out of interest can you check the number of SSTables reported by nodetool
cfstats for a CF against the number of *-Data.db f
> On Wed, May 8, 2013 at 10:43 PM, Nicolai Gylling wrote:
>> At the time of normal operation there was 800 gb free space on each node.
>> After the crash, C* started using a lot more, resulting in an
>> out-of-diskspace situation on 2 nodes, eg. C* used up the 800 gb in just 2
>> days, giving us v
On Wed, May 8, 2013 at 10:43 PM, Nicolai Gylling wrote:
> At the time of normal operation there was 800 gb free space on each node.
> After the crash, C* started using a lot more, resulting in an
> out-of-diskspace situation on 2 nodes, eg. C* used up the 800 gb in just 2
> days, giving us very li
Nicolai,
Perhaps you can check the system.log to see if there are any errors on
compaction. Also, I believe C* 1.2.0 it's not a stable version.
On Thu, May 9, 2013 at 2:43 AM, Nicolai Gylling wrote:
> Hi
>
> I have a 3-node SSD-based cluster, with around 1 TB data, RF:3, C*
> v.1.2.0, vnodes
Hi
I have a 3-node SSD-based cluster, with around 1 TB data, RF:3, C* v.1.2.0,
vnodes. One large CF, LCS. Everything was running smooth, until one of the
nodes crashed and was restarted.
At the time of normal operation there was 800 gb free space on each node.
After the crash, C* started using a
