[
https://issues.apache.org/jira/browse/CASSANDRA-8341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229780#comment-14229780
]
Benedict commented on CASSANDRA-8341:
-------------------------------------
SEPWorker already grabs the nanoTime on exiting and entering its spin phase, so
tracking this would be pretty much free (we'd need to check it once if we
swapped the executor we're working on without entering a spinning state).
Flushing pent up data is pretty trivial; you can set a max time to buffer, so
it ensures it's never more than a few seconds (or millis) out of date, say.
Enough to keep the cost too small to measure.
I'm a little dubious about tracking two completely different properties as the
same thing though. CPUTime cannot be composed with nanoTime sensibly, so we
either want to track one or the other across all executors. Since the other
executors are all the ones that do infrequent expensive work (which is
explicitly why they haven't been transitioned to SEP), tracking nanoTime on
them won't be an appreciable cost.
> Expose time spent in each thread pool
> -------------------------------------
>
> Key: CASSANDRA-8341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8341
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Chris Lohfink
> Priority: Minor
> Labels: metrics
> Attachments: 8341.patch, 8341v2.txt
>
>
> Can increment a counter with time spent in each queue. This can provide
> context on how much time is spent percentage wise in each stage.
> Additionally can be used with littles law in future if ever want to try to
> tune the size of the pools.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
