[
https://issues.apache.org/jira/browse/CASSANDRA-14436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569021#comment-16569021
]
ASF GitHub Bot commented on CASSANDRA-14436:
--------------------------------------------
Github user dineshjoshi commented on the issue:
https://github.com/apache/cassandra/pull/244
Stepping back a bit, I see the samplers are stateful classes that are
enabled and disabled. This means, if there is an exception in the rmi thread
that is executing the `beginLocalSampling` and `finishLocalSampling`, the
samplers will continue to run indefinitely and this might cause issues. It
would be best to instantiate Samplers on demand with a specific Duration. Each
sampler can stop accepting new samples once the duration expires. This would
also mean that you no longer have to keep enabling disabling samplers -
allowing you to get rid of `enabled` and other internal state variables could
be made immutable for example in `FrequencySampler`, `StreamSummary` can be
declared as `final` and initialized in the constructor.
If you want all samplers to start sampling exactly at the same moment (not
sure if that is a requirement) then you could potentially use a shared
countdown latch. The thread instantiating the samplers can decrement it once it
is done creating and initializing all samplers. WDYT?
> Add sampler for query time and expose with nodetool
> ---------------------------------------------------
>
> Key: CASSANDRA-14436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14436
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Chris Lohfink
> Assignee: Chris Lohfink
> Priority: Major
>
> Create a new {{nodetool profileload}} that functions just like toppartitions
> but with more data, returning the slowest local reads and writes on the host
> during a given duration and highest frequency touched partitions (same as
> {{nodetool toppartitions}}). Refactor included to extend use of the sampler
> for uses outside of top frequency (max instead of total sample values).
> Future work to this is to include top cpu and allocations by query and
> possibly tasks/cpu/allocations by stage during time window.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
