[
https://issues.apache.org/jira/browse/CASSANDRA-8341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219444#comment-14219444
]
Chris Lohfink commented on CASSANDRA-8341:
------------------------------------------
In the SEPExecutor since the same thread will continually execute tasks if
theres work, I think its possible to just collect the start time before
starting any work and then the end time once theres a gap in processing. This
way if the thread pool is saturated it should incur no overhead from
monitoring, but once there is a break in the work or a executor has run out of
task permits it would update the cpu time. Then on a saturated system, the
metric may be out of date but would have less of an overhead. I am not
completely familiar with the SEPWorker so I need to do a little more research,
but would that be adequate?
The type of work in tasks using the ThreadPoolExecutor (i.e. migration,
repairs, commitlog archiver etc) I don't think would be impacted from the
metrics overhead so can probably stick with impl used in the patched
JMXEnabledThreadPoolExecutor with cpu time instead of nanotime.
> 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)
