Mostly this sounds like a problem that could be cured with autowarming. But two things are conflicting here: 1> you say "We have a requirement to have updates available immediately (NRT)" 2> your docs aren't available for 120 seconds given your autoSoftCommit settings unless you're specifying -Dsolr.autoSoftCommit.maxTime=some_other_interval as a startup parameter.
So assuming you really do have a 120 second autocommit time, you should be able to smooth out the spikes by appropriate autowarming. You also haven't indicated what your filterCache and queryResultCache settings are. They come with a default of 0 for autowarm. But what is their size? And do you see a correlation between longer queries every on 2 minute intervals? And do you have some test harness in place (jmeter works well) to demonstrate that differences in your configuration help or hurt? I can't over-emphasize the importance of this, otherwise if you rely on somebody simply saying "it's slow" you have no way to know what effect changes have. Best, Erick On Thu, Jul 21, 2016 at 11:22 PM, Shawn Heisey <apa...@elyograg.org> wrote: > On 7/21/2016 11:25 PM, Rallavagu wrote: >> There is no other software running on the system and it is completely >> dedicated to Solr. It is running on Linux. Here is the full version. >> >> Linux version 3.8.13-55.1.6.el7uek.x86_64 >> (mockbu...@ca-build56.us.oracle.com) (gcc version 4.8.3 20140911 (Red >> Hat 4.8.3-9) (GCC) ) #2 SMP Wed Feb 11 14:18:22 PST 2015 > > Run the top program, press shift-M to sort by memory usage, and then > grab a screenshot of the terminal window. Share it with a site like > dropbox, imgur, or something similar, and send the URL. You'll end up > with something like this: > > https://www.dropbox.com/s/zlvpvd0rrr14yit/linux-solr-top.png?dl=0 > > If you know what to look for, you can figure out all the relevant memory > details from that. > > Thanks, > Shawn >
