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

Gus Heck commented on SOLR-3443:
--------------------------------

Was working on something else and thinking about memory consistency when it 
occurred to me that this patch might need a couple of tweaks to the Dictionary 
class to ensure that it's loading *happens before* any look ups... unless there 
is some point in the overall solr initialization phase that ensures that 
request handling threads and the core initialization threads all lock and 
unlock the same monitor before requests are handled? Does that exist somewhere? 
Memory consistency seems like something that must have already been thought 
about...  Will think more and look at it tonight.

In any case this should not effect the general resource sharing patch in 
SOLR-8349 unless I decide to add further _caveat emptor_ warnings to the 
javadoc :).

> Optimize hunspell dictionary loading with multiple cores
> --------------------------------------------------------
>
>                 Key: SOLR-3443
>                 URL: https://issues.apache.org/jira/browse/SOLR-3443
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Luca Cavanna
>         Attachments: SOLR-3443.patch, Screen Shot 2015-11-29 at 9.52.06 AM.png
>
>
> The Hunspell dictionary is actually loaded into memory. Each core using 
> hunspell loads its own dictionary, no matter if all the cores are using the 
> same dictionary files. As a result, the same dictionary is loaded into memory 
> multiple times, once for each core. I think we should share those 
> dictionaries between all cores in order to optimize the memory usage. In 
> fact, let's say a dictionary takes 20MB into memory (this is what I 
> detected), if you have 20 cores you are going to use 400MB only for 
> dictionaries, which doesn't seem a good idea to me.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to