AFAIK, the shareSchema flag which shares the same internal schema object is _NOT_ honored in SolrCloud mode. Could you raise a JIRA to the effect of "Investigate honoring shareSchema in Cloud mode"? Please add in a note about the case you're seeing.
Not promising to actually work on it, but it would be good to have a marker. Sharing the same solrconfig object is not supported even in non-cloud mode, we've looked at it upon occasion but it seems too invasive. It sounds like the schema object is where you're having space issues anyway, is that true? Best, Erick On Mon, Jul 27, 2015 at 8:16 AM, Olivier <olivau...@gmail.com> wrote: > Hi, > > I have a SolrCloud cluster with 3 nodes : 3 shards per node and > replication factor at 3. > The collections number is around 1000. All the collections use the same > Zookeeper configuration. > So when I create each collection, the ZK configuration is pulled from ZK > and the configuration files are stored in the JVM. > I thought that if the configuration was the same for each collection, the > impact on the JVM would be insignifiant because the configuration should be > loaded only once. But it is not the case, for each collection created, the > JVM size increases because the configuration is loaded again, am I correct ? > > If I have a small configuration folder size, I have no problem because the > folder size is less than 500 KB so if we count 1000 collections x 500 KB, > the JVM impact is 500 MB. > But we manage a lot of languages with some dictionaries so the > configuration folder size is about 6 MB. The JVM impact is very important > now because it can be more than 6 GB (1000 x 6 MB). > > So I would like to have the feeback of people who have a cluster with a > large number of collections too. Do I have to change some settings to > handle this case better ? What can I do to optimize this behaviour ? > For now, we just increase the RAM size per node at 16 GB but we plan to > increase the collections number. > > Thanks, > > Olivier
