1) Use fewer segments. 2) Start the service with a higher limit on the number of open files. It used to be that the kernel allocated fixed resources for maximum number, but that is no longer true. This is not really an important limit. 3) That Lucene issue was closed in 3.1. This must be some other problem. 4) You can pick another merge policy if TieredMergePolicy does not work for you.
----- Original Message ----- | From: "Sujatha Arun" <suja.a...@gmail.com> | To: solr-user@lucene.apache.org | Sent: Tuesday, September 18, 2012 10:12:13 AM | Subject: Compond File Format Advice needed - On migration to 3.6.1 | | Hi , | | The default Index file creation format in 3.6.1 [migrating from 1.3] | in-spite of setting the usecompoundfile to true seems to be to | create non | compound files due to Lucene | 2790<https://issues.apache.org/jira/browse/LUCENE-2790> | . | | I have tried the following ,but everything seems to create non | compound | files .. | | | - set compound file format to true | - used the TieredMergePolicy, did not change maxMergeAtOnce and | segmentsPerTier. | - switched back to LogByteSizeMergePolicy but this also creates | non | compound files | | We are in a situation where we have several cores and hence several | indexes | ,and do not want to run into too many open files error. What can be | done to | switch to compound file format from the beginning or will this | TiredMergepolicy lead us to too many open files eventually? | | Regards | Sujatha |
