I am on 4.2.1 @Yonik Seeley I do understand the cost and run it once per 24 hours and perhaps later this interval will be increased up to a few days.
In general I am optimizing not to merge the fragments but to remove deleted docs. My index refreshes quickly and number of deleted docs could reach a few millions per week. The questions is: if optimize does the same what the hard commit does + some other optimizations why does Solr schedule a new commit when optimize is in the process? That's the problem. Since I am optimizing once per day and all commits are scheduled by Solr itself: <autoCommit> <maxDocs>25000</maxDocs> <maxTime>300000</maxTime> <openSearcher>false</openSearcher> </autoCommit> <autoSoftCommit> <maxTime>5000</maxTime> </autoSoftCommit> If Solr see that an optimization procedure is running it could delay all scheduled hard commits until optimization is complete. Additionally it could perform a soft commit (for cases when application need to see the updated docs in index and fires commits) and run the delayed hard commit when optimization is complete. It will warm a new searcher but at least will prevent from multiple searchers warming simultaneously. Best, Alex -- View this message in context: http://lucene.472066.n3.nabble.com/Overlapping-onDeckSearchers-2-tp772556p4066267.html Sent from the Solr - User mailing list archive at Nabble.com.
