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
