You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by David Giffin <da...@giffin.org> on 2009/01/16 01:41:51 UTC

New Searcher / Commit / Cache Warming Time

Hi All,

I have been trying to reduce the cpu load and time it takes to put a
new snapshot in place on our slave servers. I have tried tweaking many
of the system memory, jvm and cache size setting used by Solr. When
running a commit from the command line I'm seeing roughly 16 seconds
before the commit completes. This is a ~7gig index with no pending
changes, nothing else running, no load:

INFO: {commit=} 0 15771
Jan 15, 2009 11:29:35 PM org.apache.solr.core.SolrCore execute
INFO: [listings] webapp=/solr path=/update params={} status=0 QTime=15771

So I started disabling things. I disabled everything under <query>
times went down:

INFO: {commit=} 0 103
Jan 15, 2009 11:35:22 PM org.apache.solr.core.SolrCore execute
INFO: [listings] webapp=/solr path=/update params={} status=0 QTime=103

So I started adding things back in, and found that adding the
<listener event="newSearcher" class="solr.QuerySenderListener">
section was causing the slow down. When I comment that section commit
times go down, the cpu spikes go away. So I tried putting the
newSearcher section back in with no queries to run, same thing...
times jump up:

INFO: {commit=} 0 16306
Jan 15, 2009 11:49:32 PM org.apache.solr.core.SolrCore execute
INFO: [listings] webapp=/solr path=/update params={} status=0 QTime=16306

Do you know what would be causing "newSearcher" to create such a
delays, and cpu spikes? Is there any reason not to disable the
"newSearcher" section?

Thanks,
David