cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9610) Increased response time with cassandra 2.0.9 from 1.2.19
Date Fri, 26 Jun 2015 21:06:05 GMT


Tyler Hobbs commented on CASSANDRA-9610:

Hmm, something weird is going on with the 1.2.19 trace -- it looks like there are other queries
mixed in.

The part of your 1.2.19 trace that made me think vnodes weren't enabled was the line:

Executing indexed scan for [min(-9223372036854775808), min(-9223372036854775808)] | 21:35:08,105
|    host1 |

However, I was incorrect about vnodes affecting that.  In order for that trace entry to happen,
host1 needs to be a replica for the entire ring.  In other words, the RF needs to match the
number of nodes in the DC.  The only other possibility that I can think of is that you have
racks (mis)configured.  For example, if host1 is on rack "A" and all of the other nodes in
the DC are on rack "B", it will be a replica for the entire ring.

Can you paste the output of {{nodetool status}} (or {{nodetool ring}}, if {{status}} doesn't
exist in 1.2)?

> Increased response time with cassandra 2.0.9 from 1.2.19
> --------------------------------------------------------
>                 Key: CASSANDRA-9610
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Maitrayee
>         Attachments: servicedefinition_schema.txt, traceout_1.2.19, traceout_2.0.9
> I was using Cassandra 1.2.19. Recently upgraded to 2.0.9. Queries with secondary index
was completing much faster in 1.2.19
> Validated this with trace on via cqlsh

This message was sent by Atlassian JIRA

View raw message