cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Lohfink (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7974) Enable tooling to detect hot partitions
Date Tue, 13 Jan 2015 21:37:38 GMT


Chris Lohfink commented on CASSANDRA-7974:

It could be made synchronous. I was a little concerned that throwing a lock in the read/write
path could affect performance enough it would Heisenberg the data. 

It being async was to avoid a synchronized block or ConcurrentStreamSummary which is slower
(jmh shows CSS ~10x) and may become a point of contention across a lot of threads. Forcing
it through a single thread fixes it and its able to actually run a lot faster then it could
concurrently.  It being in TRACING was just because I was thinking its pretty similar in being
a sampling of queries and overflow safe to throw away, its been a few months though so I can't
remember the exact train of thought. Its trivial to add another executor though if thats cleaner.

Would it work to convert from byte[] to String in the jmx operation (finishLocalSampling)?

> Enable tooling to detect hot partitions
> ---------------------------------------
>                 Key: CASSANDRA-7974
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Brandon Williams
>            Assignee: Chris Lohfink
>             Fix For: 2.1.3
>         Attachments: 7974.txt, cassandra-2.1-7974v2.txt
> Sometimes you know you have a hot partition by the load on a replica set, but have no
way of determining which partition it is.  Tracing is inadequate for this without a lot of
post-tracing analysis that might not yield results.  Since we already include stream-lib for
HLL in compaction metadata, it shouldn't be too hard to wire up topK for X seconds via jmx/nodetool
and then return the top partitions hit.

This message was sent by Atlassian JIRA

View raw message