You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Joel Knighton (JIRA)" <ji...@apache.org> on 2015/11/30 22:00:12 UTC
[jira] [Comment Edited] (CASSANDRA-10018) Stats for several pools
removed from nodetool tpstats output
[ https://issues.apache.org/jira/browse/CASSANDRA-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032444#comment-15032444 ]
Joel Knighton edited comment on CASSANDRA-10018 at 11/30/15 8:59 PM:
---------------------------------------------------------------------
This regression was introduced because of a change in metrics. When we bumped the version of metrics in [CASSANDRA-5657], changes in the metrics library changed the mapping between metrics and JMX.
Because this broke the old way we were querying for threadpool information in JMX, we switched to storing information related to the query with each {{Stage}}, as we needed to store some information in able to get the correct metrics.
I've reworked this so that we directly query JMX for threadpools and then query the related mBeans. This is a little more complicated than the old approach, but it means we know longer rely on information associated with each {{Stage}}, so it works for all threadpools.
Due to minor formatting changes, the patch for 2.2 does not apply cleanly up. I've made patches to 2.2 and 3.0. The 3.0 patch merges cleanly up.
||branch||testall||dtest||
|[10018-2.2|https://github.com/jkni/cassandra/tree/10018-2.2]|[testall|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-10018-2.2-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-10018-2.2-dtest]|
|[10018-3.0|https://github.com/jkni/cassandra/tree/10018-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-10018-3.0-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-10018-3.0-dtest]|
CI is clean relative to upstream.
EDIT: I should note that I've manually verified that all threadpools are visible after this in tpstats and {{StatusLogger}}.
was (Author: jkni):
This regression was introduced because of a change in metrics. When we bumped the version of metrics in [CASSANDRA-5657], changes in the metrics library changed the mapping between metrics and JMX.
Because this broke the old way we were querying for threadpool information in JMX, we switched to storing information related to the query with each {{Stage}}, as we needed to store some information in able to get the correct metrics.
I've reworked this so that we directly query JMX for threadpools and then query the related mBeans. This is a little more complicated than the old approach, but it means we know longer rely on information associated with each {{Stage}}, so it works for all threadpools.
Due to minor formatting changes, the patch for 2.2 does not apply cleanly up. I've made patches to 2.2 and 3.0. The 3.0 patch merges cleanly up.
||branch||testall||dtest||
|[10018-2.2|https://github.com/jkni/cassandra/tree/10018-2.2]|[testall|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-10018-2.2-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-10018-2.2-dtest]|
|[10018-3.0|https://github.com/jkni/cassandra/tree/10018-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-10018-3.0-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-10018-3.0-dtest]|
CI is clean relative to upstream.
> Stats for several pools removed from nodetool tpstats output
> -------------------------------------------------------------
>
> Key: CASSANDRA-10018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10018
> Project: Cassandra
> Issue Type: Bug
> Components: Observability
> Reporter: Sam Tunnicliffe
> Assignee: Joel Knighton
> Fix For: 2.2.x
>
>
> With CASSANDRA-5657, the output of nodetool tpstats changed to only include threadpool info for actual Stages. There are a number of
> JMX enabled thread pool executors which we used to include in tpstats and that are still in use but no longer show up.
> Before CASSANDRA-5657
> {noformat}
> Pool Name Active Pending Completed Blocked All time blocked
> MutationStage 0 0 0 0 0
> ReadStage 0 0 0 0 0
> RequestResponseStage 0 0 0 0 0
> ReadRepairStage 0 0 0 0 0
> CounterMutationStage 0 0 0 0 0
> MiscStage 0 0 0 0 0
> HintedHandoff 0 1 0 0 0
> GossipStage 0 0 0 0 0
> CacheCleanupExecutor 0 0 0 0 0
> InternalResponseStage 0 0 0 0 0
> CommitLogArchiver 0 0 0 0 0
> CompactionExecutor 0 0 48 0 0
> ValidationExecutor 0 0 0 0 0
> MigrationStage 0 0 2 0 0
> AntiEntropyStage 0 0 0 0 0
> PendingRangeCalculator 0 0 1 0 0
> Sampler 0 0 0 0 0
> MemtableFlushWriter 0 0 14 0 0
> MemtablePostFlush 0 0 20 0 0
> MemtableReclaimMemory 0 0 14 0 0
> Message type Dropped
> READ 0
> RANGE_SLICE 0
> _TRACE 0
> MUTATION 0
> COUNTER_MUTATION 0
> BINARY 0
> REQUEST_RESPONSE 0
> PAGED_RANGE 0
> READ_REPAIR 0
> {noformat}
> After CASSANDRA-5657
> {noformat}
> Pool Name Active Pending Completed Blocked All time blocked
> ReadStage 0 0 0 0 0
> MutationStage 0 0 0 0 0
> CounterMutationStage 0 0 0 0 0
> GossipStage 0 0 0 0 0
> RequestResponseStage 0 0 0 0 0
> AntiEntropyStage 0 0 0 0 0
> MigrationStage 0 0 2 0 0
> MiscStage 0 0 0 0 0
> InternalResponseStage 0 0 0 0 0
> ReadRepairStage 0 0 0 0 0
> Message type Dropped
> READ 0
> RANGE_SLICE 0
> _TRACE 0
> MUTATION 0
> COUNTER_MUTATION 0
> BINARY 0
> REQUEST_RESPONSE 0
> PAGED_RANGE 0
> READ_REPAIR 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)