Re: weird jvm metrics

On 01/04/2017 11:12 PM, Edward Capriolo wrote: The metric-reporter is actually leveraged from another project. https://github.com/addthis/metrics-reporter-config Check the version of metric-reporter (in cassandra/lib) and see if it has changed from your old version to your new version. On

Re: weird jvm metrics

On 01/05/2017 07:59 PM, Edward Capriolo wrote: Good troubleshooting. I would open a Jira. It seems like a good solution would be to replace '..' with '.' somehow. It seems like no one would every want .. In my case with logstash it was not really a problem, in case of the OP, may be it is a

Troubleshooting random node latency spikes

Greetings! I'm working on setting up a new cassandra cluster with a write-heavy workload (50% writes), and I've run into a strange spiky latency problem. My application metrics showed random latency spikes. I tracked the latency back to spikes on individual cassandra nodes. 

Re: weird jvm metrics

On Thu, Jan 5, 2017 at 1:53 PM, Alain Rastoul wrote: > On 01/04/2017 11:12 PM, Edward Capriolo wrote: > >> The metric-reporter is actually leveraged from another project. >> >> https://github.com/addthis/metrics-reporter-config >> >> Check the version of metric-reporter

Re: Cassandra cluster performance

you should try switching to async writes and then perform the test. sync writes won't make much difference from a single node but multiple nodes there should be a massive difference. On 4 Jan 2017 10:05, "Branislav Janosik -T (bjanosik - AAP3 INC at Cisco)" < bjano...@cisco.com> wrote: > Hi, > >

Re: Odd behavior when querying using two SASI indexes

Opened https://issues.apache.org/jira/browse/CASSANDRA-13105 because it does seem like this should work. On Wed, Jan 4, 2017 at 5:53 PM, Voytek Jarnot wrote: > Seeing queries return 0 rows incorrectly, running 3.9 > > Setup: > > create table test1(id1 text PRIMARY KEY,

Streaming error during repair

Hi guys, While running repairs, I see this on one box: *ERROR [RepairJobTask:19] 2017-01-05 09:12:36,940 RepairSession.java:290 - [repair #3747c581-d325-11e6-92ea-130d59760dad] Session completed with the following error* *org.apache.cassandra.exceptions.RepairException: [repair

Re: Why compacting process uses more data that is expected

Hi Alexander, It would actually be a great improvement for ops if we could add a switch to compactionstats in order to have the compression ratio applied automatically. Yes actually that can be nice. Thank you guys for you reply. I have 34GB in total size of our sstable @Jonathan Haddad. And

Re: Streaming error during repair

Fixed on https://issues.apache.org/jira/browse/CASSANDRA-12905 (still to be released). If you're running repair of all keyspace or tables in a single command, run each table separately and should improve things a bit. 2017-01-05 7:54 GMT-02:00 Robert Sicoie : > Hi guys,

Re: Streaming error during repair

Yes, I am running repairs in one single command. Thanks Paulo! Robert Sicoie On Thu, Jan 5, 2017 at 1:59 PM, Paulo Motta wrote: > Fixed on https://issues.apache.org/jira/browse/CASSANDRA-12905 (still to > be released). If you're running repair of all keyspace or

[C* 2.1.14] Not enough bytes exception during compaction

Hi, We recently got an exception during compaction on some nodes (Cassandra 2.1.14): ERROR [CompactionExecutor:14065] 2016-12-30 14:45:07,245 CassandraDaemon.java:229 - Exception in thread Thread[CompactionExecutor:14065,1,main] java.lang.IllegalArgumentException: Not enough bytes. Offset: