[
https://issues.apache.org/jira/browse/SOLR-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587472#comment-16587472
]
Shawn Heisey commented on SOLR-12672:
-------------------------------------
I think that in order for this idea to be safe, the max heap needs to be larger
than what that install of Solr would normally need -- to ensure that there's
enough heap memory that Java won't ever decide to do a GC on its own. The
explicit GCs should be the *only* GCs that occur.
If the explicit GCs take more than about one second, then I think the entire
idea is problematic. If a heap size of 8GB makes the explicit GCs take 10
seconds or longer, it's a REALLY bad idea. I'd rather deal with subsecond
pauses on an unpredictable interval than that scenario.
If we can do what Erick seems to be suggesting and synchronize pauses on one
replica at a time, with overseer updates telling SolrCloud to NOT use those
replicas until the synchronized event is done, that MIGHT eliminate all
concerns. It would mean that this must be a cloud-only feature. And if the
pauses are longer than five seconds for larger heaps, that's a problem.
> Implement Synchronized Disruption into Solr
> -------------------------------------------
>
> Key: SOLR-12672
> URL: https://issues.apache.org/jira/browse/SOLR-12672
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Trey Cahill
> Priority: Trivial
> Attachments: Synchronized Disruption in Solr.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On large Solr clusters, at any given time, there is probably an instance
> running garbage collection. By implementing a synchronized disruption across
> the entire cluster, the response times of a large cluster should decrease as
> it helps prevent random instances from running GC while the rest of the
> cluster is responding to a request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
