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 > > > >
