[
https://issues.apache.org/jira/browse/IGNITE-27808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Korol updated IGNITE-27808:
--------------------------------
Description:
Currently we register each stripe of StripedExecutor implementation in metrics
subsytem. As a result each stripe expose following metrics:
{code:java}
stripe.0.PoolSize=0
stripe.0.QueueSize=0
stripe.0.TaskCount=0
stripe.1.ActiveCount=0
stripe.1.CompletedTaskCount=0
stripe.1.CorePoolSize=1
stripe.1.KeepAliveTime=0
stripe.1.LargestPoolSize=0
stripe.1.MaximumPoolSize=1 {code}
It seems like major part of them are meaningless since each stripe is
single-thread executor:
{code:java}
CorePoolSize # Static setting. Can't be changed
MaximumPoolSize # No use in realtime and for stripe it always equal to 1
PoolSize # In case of Stripped it's either 0 or 1, and we can
infer it from other metric like ActiveCount
LargestPoolSize # In case of given stripe it can be only 1 - no real use
KeepAliveTime # Static setting. AFAICS it always 0 {code}
It looks like we can safely remove them.
At the same time due to nature of StripedExecutors it worth to implement
aggregated metrics that will embrace all stripes for given executor. Consider
the metrics dump that AI2 prints to logs periodically:
{code:java}
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=22, qSize=0]
^-- Striped thread pool [active=0, idle=22, qSize=0] {code}
So aggregated form like this allows us to make conclusion about load patterns.
For instance there can be a situation when only particular stripe in Stripped
pools is overloaded, in this case we'll see that there still few idle threads
despite {{{}qSize > 0{}}}.
> Implement metrics agregation for striped executors
> --------------------------------------------------
>
> Key: IGNITE-27808
> URL: https://issues.apache.org/jira/browse/IGNITE-27808
> Project: Ignite
> Issue Type: Improvement
> Components: metrics ai3
> Affects Versions: 3.1
> Reporter: Ilya Korol
> Assignee: Vyacheslav Koptilin
> Priority: Major
>
> Currently we register each stripe of StripedExecutor implementation in
> metrics subsytem. As a result each stripe expose following metrics:
> {code:java}
> stripe.0.PoolSize=0
> stripe.0.QueueSize=0
> stripe.0.TaskCount=0
> stripe.1.ActiveCount=0
> stripe.1.CompletedTaskCount=0
> stripe.1.CorePoolSize=1
> stripe.1.KeepAliveTime=0
> stripe.1.LargestPoolSize=0
> stripe.1.MaximumPoolSize=1 {code}
> It seems like major part of them are meaningless since each stripe is
> single-thread executor:
> {code:java}
> CorePoolSize # Static setting. Can't be changed
> MaximumPoolSize # No use in realtime and for stripe it always equal
> to 1
> PoolSize # In case of Stripped it's either 0 or 1, and we can
> infer it from other metric like ActiveCount
> LargestPoolSize # In case of given stripe it can be only 1 - no real
> use
> KeepAliveTime # Static setting. AFAICS it always 0 {code}
> It looks like we can safely remove them.
>
> At the same time due to nature of StripedExecutors it worth to implement
> aggregated metrics that will embrace all stripes for given executor. Consider
> the metrics dump that AI2 prints to logs periodically:
> {code:java}
> ^-- Public thread pool [active=0, idle=0, qSize=0]
> ^-- System thread pool [active=0, idle=22, qSize=0]
> ^-- Striped thread pool [active=0, idle=22, qSize=0] {code}
> So aggregated form like this allows us to make conclusion about load
> patterns. For instance there can be a situation when only particular stripe
> in Stripped pools is overloaded, in this case we'll see that there still few
> idle threads despite {{{}qSize > 0{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
