Re: Does async read repair happen when using CL.LOCAL_QUORUM?

2017-09-25 Thread Lutaya Shafiq Holmes
Let me see On 9/25/17, 孟靖 wrote: > Hi, I’ve read the code concerning read_repair when the ReadRepairDecision is > GLOBAL with CL = LOCAL_QUORUM in cassandra-2.1.18. > > It concerns me that when using CL.LOCAL_QUORUM, there was a if statement: > > `If (blockfor < endpoints.size() && n == endpo

[3.0.14] Thrift works fine, CQL/Native queries give nonsensical results

2017-09-25 Thread Michiel Buddingh
LS, We are currently in the process of migrating data from an old Cassandra cluster to a new one. When quering data from a table that was copied using sstableloader, we find that even at consistency level ALL, results contain 200% duplicate entries, or worse, keep paginating and repeating th

RE: GC/CPU increase after upgrading to 3.0.14 (from 2.1.18)

2017-09-25 Thread Steinmaurer, Thomas
Hello, I have now some concrete numbers from our 9 node loadtest cluster with constant load, same infrastructure after upgrading to 3.0.14 from 2.1.18. We see doubled GC suspension time + correlating CPU increase. In short, 3.0.14 is not able to handle the same load. I have created https://iss

Analysis of the jvm heap cassandra

2017-09-25 Thread Jean Carlo
Hello community, I am analysing a dump of 11GB and I am using eclipse memory analyser. I would like to know if you guys really need a machine with 32GB to analyse a dump of G1GC of 30GB or there is another smarter way to do that. Greetings Jean Carlo "The best way to predict the future is to i

Re: Analysis of the jvm heap cassandra

2017-09-25 Thread Eric Evans
On Mon, Sep 25, 2017 at 7:02 AM, Jean Carlo wrote: > I am analysing a dump of 11GB and I am using eclipse memory analyser. > > I would like to know if you guys really need a machine with 32GB to analyse > a dump of G1GC of 30GB or there is another smarter way to do that. It's been my experience t

User Defined Compaction Issue

2017-09-25 Thread shalom sagges
Hi Everyone, I'm running into an issue I can't seem to Solve. I execute force compaction in order to reclaim back storage. Everything was working fine for a time, but after a while I found that tombstones aren't being removed any longer. For example, I've compacted the following SSTable: *21G *S

Re: User Defined Compaction Issue

2017-09-25 Thread Jeff Jirsa
The problem is likely that your sstables overlap - your 91% droppable tombstones are probably covering data in another file. Until that data is removed, those tombstones cant be dropped. This is why a full major compaction often works better for simply reclaiming disk space (though it takes a lot