[ 
https://issues.apache.org/jira/browse/SOLR-18284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18091649#comment-18091649
 ] 

ASF subversion and git services commented on SOLR-18284:
--------------------------------------------------------

Commit e280fd37ef6220e33d748cf26f21299265f5803b in solr's branch 
refs/heads/branch_10x from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=e280fd37ef6 ]

SOLR-18284: Load-average and memory circuit breakers no longer stampede or trip 
on transient pre-GC heap peaks (#4549)

> Fix load-average and memory circuit breakers
> --------------------------------------------
>
>                 Key: SOLR-18284
>                 URL: https://issues.apache.org/jira/browse/SOLR-18284
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Mark Robert Miller
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 5h 50m
>  Remaining Estimate: 0h
>
> Load-average and memory circuit breakers were doing more harm than good under 
> high concurrency.
> LoadAverageCircuitBreaker called OperatingSystemMXBean.getSystemLoadAverage() 
> on every request. The OS load average is a one-minute moving average, so 
> re-polling it per-request is wasted work - and when many requests arrived 
> concurrently, the syscall stampede hammered the CPU, which is the condition 
> this breaker exists to prevent rather than cause.
> MemoryCircuitBreaker sampled MemoryMXBean.getHeapMemoryUsage().getUsed() on a 
> 30-second moving average. With a generational collector that signal climbs 
> toward max between collections during normal operation; the breaker would 
> trip on transient pre-GC peaks that GC was about to reclaim.
> * I extracted these from the experimental circuit breaker overhaul PR.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to