Solr requests time out during index update. Perhaps replication a possible solution?

Question

We are running a Solr installation (everything standard jetty environment, just added some fields to schema).

The index is about 80k Documents that are of average si

Answer 1

The only reason that I can think a searcher would be slow is if it is rebuilding its caches. Are you warming up your searchers with useful queries?

My thinking...

Updates in and of themselves won't block reads or writes. A commit will block writes as it flushes the writer, but not reads. One updates are flushed, a new searcher is then initialized, warmed, and then swapped out in place of the old searcher.

If at this point your searches are timing out, it could be that your first few handfuls of requests are heavily IO bound while warming up caches that later searches depend on. Hence I'm wondering if your searchers are being warmed up with useful queries.

For the sake of discussion, here's the sample newSearcher warming query present in most default-ish solrconfig.xml files:

<listener event="newSearcher" class="solr.QuerySenderListener">
  <arr name="queries">
    <lst>
      <str name="q">solr</str>
      <str name="start">0</str>
      <str name="rows">10</str>
    </lst>
    <lst>
      <str name="q">rocks</str>
      <str name="start">0</str>
      <str name="rows">10</str>
    </lst>
  </arr>
</listener>

Perhaps you're still using this? :)

Replication could be a great way to go in this kind of scenario. However, you may already have a similar mechanism in place that you can put to better use.

Answer 2

If you only see it occasionally, and the number of documents keeps increasing, you're likely hitting the merge limit. Merging is horrendously expensive as old segments are turned into new segments, and your caches all get dumped to boot.

You definitely want to do a master/slave setup, SWAP (as seen above), etc. to smooth over the bumps.

Answer 3

You're mostly on the right track. One way to solve this is to use a second core for updates, then when this second is fully updated and committed, you SWAP it with the first core and make it the active one.

I think this approach is described in more detail in the book "Solr 1.4 Enterprise Search Server" (here's a snippet)