[
https://issues.apache.org/jira/browse/SOLR-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16584632#comment-16584632
]
Shawn Heisey commented on SOLR-12672:
-------------------------------------
As far as I am aware, if you ask Java for an explicit GC, it's going to be a
*full* GC. Does your experience align with this? I suppose you can use jstat
or jconsole to monitor a JVM that is doing the synchronized disruption, see
whether the full GC counter or one of the generation-specific counters is
incrementing. Are you tracking how long the System.gc() call takes in your
code that does this synchronization?
I found the secret to good GC tuning is to give Java parameters that allow it
to *avoid* doing full garbage collections, freeing up plenty of memory using
only the generation-specific collectors, which run much faster and tend to
create short pauses.
A full GC, no matter which collector you have configured, is going to be slow.
With an 8GB heap and no tuning beyond either choosing G1 or CMS, I was seeing
full GCs happen regularly, and there were pauses of 10-15 seconds every time
Java did a full GC. With good tuning, full GCs became extremely rare. If one
did happen for some reason, there was still a long pause.
Do you find that explicit GCs done on a regular basis perform faster than
several seconds? If a scheduled GC does take several seconds, and this happens
on every machine in the cluster at the same time, that would be a worse problem
than an extra hundred milliseconds every now and then.
> 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]
