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

Shawn Heisey commented on LUCENE-4740:
--------------------------------------

I've been watching the activity on this issue because I have occasional extreme 
GC pauses in Solr with an 8GB heap.  GC tuning has reduced them somewhat so 
that my load balancer hasn't marked the service offline in a few days, but I 
think that things still aren't ideal.

I will admit that I find most of the comments baffling.  Therefore I have a 
simple question.  If I run Solr branch_4x with this patch applied, will I 
benefit?  I can see from the commit log that unmmapping must disabled to 
benefit, but I don't know if this is how Solr operates.

                
> Weak references cause extreme GC churn
> --------------------------------------
>
>                 Key: LUCENE-4740
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4740
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: core/store
>    Affects Versions: 3.6.1
>         Environment: Linux debian squeeze 64 bit, Oracle JDK 6, 32 GB RAM, 16 
> cores
> -Xmx16G
>            Reporter: Kristofer Karlsson
>             Fix For: 4.2, 5.0
>
>         Attachments: LUCENE-4740.patch, LUCENE-4740.patch
>
>
> We are running a set of independent search machines, running our custom 
> software using lucene as a search library. We recently upgraded from lucene 
> 3.0.3 to 3.6.1 and noticed a severe degradation of performance.
> After doing some heap dump digging, it turns out the process is stalling 
> because it's spending so much time in GC. We noticed about 212 million 
> WeakReference, originating from WeakIdentityMap, originating from 
> MMapIndexInput.
> Our problem completely went away after removing the clones weakhashmap from 
> MMapIndexInput, and as a side-effect, disabling support for explictly 
> unmapping the mmapped data.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Reply via email to