[
https://issues.apache.org/jira/browse/SOLR-15056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17307575#comment-17307575
]
Atri Sharma commented on SOLR-15056:
------------------------------------
I am sorry, but I have to disagree on some aspects.
# The current circuit breaker publishes what it uses and if the documentation
is not appropriate, we should fix it.
# I still do not see what is it that has been fixed in the existing tests –
there is a new circuit breaker implementation, there are tests for that (thank
you!). Beyond that, does this patch fix anything in existing tests that I am
missing?
# I am fine with the elaboration (JMX, search requests) but I am not sure
about the grammar and wording, hence I would want Cassandra's opinion there.
In entirety, I agree that the documentation should be extended to highlight
more of JMX metrics that we use. The way the framework is built, it is fairly
straightforward to implement a new circuit breaker. Hence, I think this patch
should be focused on two things: improving documentation and add the new
circuit breaker, and the messaging around this Jira should reflect that.
> CPU circuit breaker needs to use CPU utilization, not Unix load average
> -----------------------------------------------------------------------
>
> Key: SOLR-15056
> URL: https://issues.apache.org/jira/browse/SOLR-15056
> Project: Solr
> Issue Type: Bug
> Components: metrics
> Affects Versions: 8.7
> Reporter: Walter Underwood
> Assignee: Atri Sharma
> Priority: Major
> Labels: Metrics
> Attachments:
> 0001-SOLR-15056-Circuit-Breakers-use-CPU-utilization-inst.patch,
> 0002-SOLR-15056-clean-up-linkage-to-SolrCore-add-back-loa.patch,
> SOLR-15056.patch
>
>
> The config range, 50% to 95%, assumes that the circuit breaker is triggered
> by a CPU utilization metric that goes from 0% to 100%. But the code uses the
> metric OperatingSystemMXBean.getSystemLoadAverage(). That is an average of
> the count of processes waiting to run. It is effectively unbounded. I've seen
> it as high as 50 to 100. It is not bound by 1.0 (100%).
> A good limit for load average would need to be aware of the number of CPUs
> available to the JVM. A load average of 8 is no problem for a 32 CPU host. It
> is a critical situation for a 2 CPU host.
> Also, load average is a Unix OS metric. I don't know if it is even available
> on Windows.
> Instead, use a CPU utilization metric that goes from 0.0 to 1.0. A good
> choice is OperatingSystemMXBean.getSystemCPULoad(). This name also uses
> "load", but it is a usage metric.
> From the Javadoc:
> > Returns the "recent cpu usage" for the whole system. This value is a double
> >in the [0.0,1.0] interval. A value of 0.0 means that all CPUs were idle
> >during the recent period of time observed, while a value of 1.0 means that
> >all CPUs were actively running 100% of the time during the recent period
> >being observed. All values betweens 0.0 and 1.0 are possible depending of
> >the activities going on in the system. If the system recent cpu usage is not
> >available, the method returns a negative value.
> https://docs.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/OperatingSystemMXBean.html#getSystemCpuLoad()
> Also update the documentation to explain which JMX metrics are used for the
> memory and CPU circuit breakers.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
