One problem here is how to open new searchers on the r/o core. Consider the autocommit setting. The cycle is > when the first doc comes in, start your timer > x milliseconds later, do a commit and (perhaps) open a new searcher.
but the core referencing the index in R/O mode doesn't have any update event to start the timer. Even if you issue a commit to the R/O copy, there is short-circuiting in the code that says "since nothing's changed, I'll just ignore this". And by definition, the commit is an update call.... I suppose you could force things here by issuing a reload command on the R/O core... WARNING: Since I strongly discourage this it's not something I've personally verified.... And the risk of corrupting your index because someone inadvertently does something unexpected is high. I always come back to the question of why in the world spend engineering time on this when the cost of a new 1TB disk is so low. I realize there are environments where you can't "just plug in another disk", but you see where I'm going. Best, Erick On Fri, May 19, 2017 at 11:47 AM, David Hastings <hastings.recurs...@gmail.com> wrote: > Mt thought would be that the machine would need only the same amount of ram > minus the heap size of the second instance of solr, since it will be file > caching the index into memory only once since its the same files, but read > by both solr instances. my solr slaves have about 150gb each. > > On Fri, May 19, 2017 at 2:45 PM, Rick Leir <rl...@leirtech.com> wrote: > >> > multiple solr instances on one machine performs better than multiple >> >> Does the machine have enough RAM to support all the instances? Again, time >> for an experiment! >> -- >> Sorry for being brief. Alternate email is rickleir at yahoo dot com
