Lucene already did that: https://issues.apache.org/jira/browse/LUCENE-3454
Here is the Solr issue: https://issues.apache.org/jira/browse/SOLR-3141 People over-use this regardless of the name. In Ultraseek Server, it was called "force merge" and we had to tell people to stop doing that nearly every month. wunder On Oct 22, 2012, at 1:39 PM, Michael Della Bitta wrote: > Has the Solr team considered renaming the optimize function to avoid > leading people down the path of this antipattern? > > Michael Della Bitta > > ------------------------------------------------ > Appinions > 18 East 41st Street, 2nd Floor > New York, NY 10017-6271 > > www.appinions.com > > Where Influence Isn’t a Game > > > On Mon, Oct 22, 2012 at 4:01 PM, Walter Underwood <wun...@wunderwood.org> > wrote: >> First, stop optimizing. You do not need to manually force merges. The system >> does a great job. Forcing merges (optimize) uses a lot of CPU and disk IO >> and might be the cause of your problem. >> >> Second, the OS will use the "extra" memory for file buffers, which really >> helps performance, so you might not need to do anything. This will work >> better after you stop forcing merges. A forced merge replaces every file, so >> the OS needs to reload everything into file buffers. >> >> wunder >> >> On Oct 22, 2012, at 12:55 PM, Dotan Cohen wrote: >> >>> On Mon, Oct 22, 2012 at 9:22 PM, Mark Miller <markrmil...@gmail.com> wrote: >>>> Perhaps you can grab a snapshot of the stack traces when the 60 second >>>> delay is occurring? >>>> >>>> You can get the stack traces right in the admin ui, or you can use >>>> another tool (jconsole, visualvm, jstack cmd line, etc) >>>> >>> Thanks. I've refactored so that the index is optimized once per hour, >>> instead after each dump of commits. But when I will need to increase >>> the optmize frequency in the future I will go through the stack >>> traces. Thanks! >>> >>> In any case, the server has an extra 14 GiB of memory available, how >>> might I make the best use of that for Solr assuming both heavy reads >>> and writes? >>> >>> Thanks. >>> >>> -- >>> Dotan Cohen >>> >>> http://gibberish.co.il >>> http://what-is-what.com >> >> >> >> -- Walter Underwood wun...@wunderwood.org
