Probably lowest effort is to run the select with tracing enabled - may give
some easy hints
--
Jeff Jirsa
> On Jan 28, 2019, at 7:54 AM, Jonathan Haddad wrote:
>
> Your fastest route might be to run a profiler on Cassandra and get some flame
> graphs. I'm a fan of the async-profiler:
>
>
Your fastest route might be to run a profiler on Cassandra and get some
flame graphs. I'm a fan of the async-profiler:
https://github.com/jvm-profiling-tools/async-profiler
Joey Lynch did a nice write up in the documentation on a different process,
which I haven't used yet:
http://cassandra.apa
Hello,
We have noticed CPU usage spike after several minutes of consistent load
when querying:
- a single column of set type (same partition key)
- relatively frequently (couple hundred times per second, for comparison,
we do an order of magnitude more reads already with much bigger payloads)
- wi
The issue in 14861 doesn’t manifest itself in the data file (so you won’t see
it in the sstable json), it’s in the min/max clustering of the metadata used in
the read path.
--
Jeff Jirsa
> On Jan 28, 2019, at 7:08 AM, Ahmed Eljami wrote:
>
> Hi Alain,
>
> Just to confirm, range tombstones
Hi Alain,
Just to confirm, range tombstones that we are talking about here is not
related to this jira: https://issues.apache.org/jira/browse/CASSANDRA-14861
?
Thanks a lot.
Hello,
@Chris, I mostly agree with you. I will try to make clear what I had in
mind, as it was not well-expressed obviously.
> it doesn't matter if the tombstone is overlapped it still need to be kept
> for the gc_grace before purging or it can result in data resurrection.
Yes, I agree. I do n
You could only have one keyspace for the value of allocate_tokens_for_keyspace
to specify a keyspace from which the algorithm can find the replication to
optimize for. So as far as your keyspaces are using similar replication
strategies and replication factor you should not worry about this.
Thanks Horia,
Yes we use Murmur3Partionner.
And yes we should have the same replication strategy for all KSs.
Le lun. 28 janv. 2019 à 10:44, Horia Mocioi a écrit :
> Hello,
>
> When configuring this option, the replication strategy of that keyspace
> will be used to optimize token selection,
Hello,
When configuring this option, the replication strategy of that keyspace
will be used to optimize token selection, so this is useful when you have a
single keyspace across the cluster or the same replication strategy for all
keyspaces.
Also, is worth noting that the option is available for
Hi Folks,
I'm about to configure a new cluster with num_token = 32 and using the new
token allocation.
For the first keyspace, I understood that it will be used to start my
cluster: allocate_tokens_for_keyspace = my_first_ks.
My question is how about the rest of keyspaces ? they will take the s
10 matches
Mail list logo
