It's not that your disks are getting full. I suspect you don't have enough
throughput to handle the type of stress compaction and memtable flushing
produce. Blocked flush writers is almost always a disk problem.
Any storage with the words SAN, NAS, NFS or SATA in them, is going to make
your life m
Hi Benedict,
This makes sense now. Thank you very much for your input.
Regards,
Vasilis
On 25 Aug 2016 10:30 am, "Benedict Elliott Smith"
wrote:
> You should update from 2.0 to avoid this behaviour, is the simple answer.
> You are correct that when the commit log gets full the memtables are
>
Hi Patrick and thanks for your reply,
We are monitoring disk usage and more and we don't seem to be running out
of space at the moment. We have separate partitions/disks for
commitlog/data. Which one do you suspect and why?
Regards,
Vasilis
On 25 Aug 2016 4:01 pm, "Patrick McFadin" wrote:
Thi
This looks like you've run out of disk. What are your hardware specs?
Patrick
On Thursday, August 25, 2016, Benedict Elliott Smith
wrote:
> You should update from 2.0 to avoid this behaviour, is the simple answer.
> You are correct that when the commit log gets full the memtables are
> flushed
You should update from 2.0 to avoid this behaviour, is the simple answer.
You are correct that when the commit log gets full the memtables are
flushed to make room. 2.0 has several interrelated problems here though:
There is a maximum flush queue length property (I cannot recall its name),
and on
Hello,
We have an 8-node cluster spread out in 2 DCs, 4 nodes in each one. We run
C* 2.0.17 on Ubuntu 12.04 at the moment.
Our C# application often throws logs, which correlate with dropped messages
(counter mutations usually) in our logs. We think that if a specific
mutaiton stays in the
