[
https://issues.apache.org/jira/browse/CASSANDRA-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275987#comment-14275987
]
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: https://issues.apache.org/jira/browse/CASSANDRA-7974
> 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
(v6.3.4#6332)
