Thanks Toke for this. It gave us a ton to think about, and it really helps supporting the notion of several smaller indexes over one very large one, where we can rather distribute a few JVM processes with less size each, than have one massive one that is according to this, less efficient.
Toke Eskildsen wrote > I would guess the 100 ms improvement was due to a factor not related to > heap size. With the exception of a situation where the heap is nearly > full, increasing Xmx will not improve Solr performance significantly. > > Quick note: Never set Xmx in the range 32GB-40GB (40GB is approximate): > At the 32GB point, the JVM switches to larger pointers, which means that > effective heap space is _smaller_ for Xmx=33GB than it is for Xmx=31GB: > https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/ > > - Toke Eskildsen, State and University Library, Denmark -- View this message in context: http://lucene.472066.n3.nabble.com/fq-degrades-qtime-in-a-20million-doc-collection-tp4250567p4251176.html Sent from the Solr - User mailing list archive at Nabble.com.
