[
https://issues.apache.org/jira/browse/LUCENE-7648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15832122#comment-15832122
]
Shawn Heisey commented on LUCENE-7648:
--------------------------------------
At this point, the assumption is that Lucene is where the time is taken, but if
it turns out that it's in Solr, we can move the issue.
> Millions of fields in an index makes some operations slow, opening a new
> searcher in particular
> -----------------------------------------------------------------------------------------------
>
> Key: LUCENE-7648
> URL: https://issues.apache.org/jira/browse/LUCENE-7648
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 4.10.4
> Reporter: Shawn Heisey
> Priority: Minor
>
> Got a Solr user who was experiencing very slow commit times on their index --
> 10 seconds or more. This is on a 650K document index sized at about 420MB,
> with all Solr cache autowarm counts at zero.
> After some profiling of their Solr install, they finally determined that the
> problem was an abuse of dynamic fields. The largest .fnm file in their index
> was 130MB, with the total of all .fnm files at 140MB. The user estimates
> that they have about 2 million fields in this index. They will be fixing the
> situation so the field count is more reasonable.
> While I do understand that millions of fields in an index is a pathological
> setup, and that some parts of Lucene operation are always going to be slow on
> an index like that, 10 seconds for a new searcher seemed excessive to me.
> Perhaps there is an opportunity for a *little* bit of optimization?
> The version is old -- 4.10.4. They have not yet tried a newer version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
