[
https://issues.apache.org/jira/browse/LUCENE-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568615#comment-13568615
]
Kristofer Karlsson commented on LUCENE-4740:
--------------------------------------------
Looks good, but what happens if you start with having useUnmap = false, then
creating a bunch of clones, and then setting it back to useUnmap = true?
If I read the code correctly (which I am not certain of), closing the original
input will then unmap the data and break all the existing clones.
> 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
> Reporter: Kristofer Karlsson
> Priority: Critical
> Attachments: 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]
