On Mon, 2017-04-10 at 13:27 +0530, Himanshu Sachdeva wrote: > Thanks for your time and quick response. As you said, I changed our > logging level from SEVERE to INFO and indeed found the performance > warning *Overlapping onDeckSearchers=2* in the logs.
If you only see it occasionally, it is probably not a problem. If you see it often, that means that you are re-opening at a high rate, relative to the time it takes for a searcher to be ready. Since each searcher holds a lock on the files it searches, and you have multiple concurrent open searchers on a volatile index, that helps explain the index size fluctuations. Each searcher also requires heap, which might explain why you get Out Of Memory errors. This all boils down to avoid having (too many) overlapping warming searchers. * Reduce your auto-warm if it is high * Prolong the time between searcher-opening commits * Check that you have docValues on fields that you facet or group on > I am considering limiting the *maxWarmingSearchers* count in > configuration but want to be sure that nothing breaks in production > in case simultaneous commits do happen afterwards. That is one way of doing it, but it does not help you pinpoint where your problem is. > What would happen if we set *maxWarmingSearchers* count to 1 and make > simultaneous commit from different endpoints? I understand that solr > will prevent opening a new searcher for the second commit but is that > all there is to it? Does it mean solr will serve stale data( i.e. > send stale data to the slaves) ignoring the changes from the second > commit? [...] Sorry, I am not that familiar with the details of master-slave-setups. -- Toke Eskildsen, Royal Danish Library
