What are your autowarm settings? You should be able to alleviate this by configuring these in solrconfig.xml 1> your cache autowarm settings, particularly filterCache and documentResultCache. 2> your newSearcher settings.
The point of all the autowarming is that these queries are executed after a commit (or replication in your situation) but _before_ the new searcher serves queries. So here's the sequence 1> a replication (or commit) happens 2> a new searcher is opened and autowarming occurs (cache autowarm and executing any newSearcher queries defined) 3> while <2> is going on, incoming queries are served by the old seacher. 4> when <2> is completed, incoming queries are served by the new searcher 5> the old searcher fulfills its last query and closes itself. Don't be confused by firstSearcher and newSearcher. firstSearcher is fired when the entire server is started (and there are no cache entries to autowarm). newSearcher queries are fired whenever a commit (or replication) happen. HOWEVER. at a 10 second refresh interval, you have the chance of <2> taking more than 10 seconds. you'll see warnings about "too many on deck searchers" if this is the case. For a M/R setup, 10 seconds is _very_ aggressive. Seriously consider SolrCloud in this case if your latency requirements are truly that low. Having your master serve queries is also suspect. It's _busy_ indexing and you're asking it to add query load too. May not really matter a lot depends on the indexing rate... Best, Erick On Tue, Aug 26, 2014 at 1:32 PM, Scott Rankin <sran...@crsinc.com> wrote: > Hi all, > > I have a scenario here and I'd love some advice on what my options are. > We have one Solr master and two read replicas. The replicas query the > master every 10 seconds because we need relatively quick availability of > new documents. We balance read queries across all three servers and send > writes only to the master. > > The problem that I'm seeing is that average query time is vastly higher on > the replicas than on the master - 150ms vs 1600ms. What I've noticed is > that immediately after a replication, a query against the replica can take > up to 5 seconds. Then subsequent queries are faster until the next > replication. On one level this makes sense, since when there's a change > to the index I imagine that the caches get flushed. But this is really > bogging down performance on a pretty high number of queries. > > We should have plenty of OS disk cache - the server has 12 GB of RAM, and > the apps on the server are only using up about 6. Our index is 2.7 GB, so > it should fit in the OS disk cache. Are there any other factors that I can > look at to eliminate these slow queries? > > Thanks, > Scott > > Scott Rankin > Corporate Reimbursement Services, Inc. > Phone: 617-467-1931 > Email: sran...@crsinc.com<mailto:sran...@crsinc.com> > > This email message contains information that Corporate Reimbursement > Services, Inc. considers confidential and/or proprietary, or may later > designate as confidential and proprietary. It is intended only for use of > the individual or entity named above and should not be forwarded to any > other persons or entities without the express consent of Corporate > Reimbursement Services, Inc., nor should it be used for any purpose other > than in the course of any potential or actual business relationship with > Corporate Reimbursement Services, Inc. If the reader of this message is not > the intended recipient, or the employee or agent responsible to deliver it > to the intended recipient, you are hereby notified that any dissemination, > distribution, or copying of this communication is strictly prohibited. If > you have received this communication in error, please notify sender > immediately and destroy the original message. > > Internal Revenue Service regulations require that certain types of written > advice include a disclaimer. To the extent the preceding message contains > advice relating to a Federal tax issue, unless expressly stated otherwise > the advice is not intended or written to be used, and it cannot be used by > the recipient or any other taxpayer, for the purpose of avoiding Federal > tax penalties, and was not written to support the promotion or marketing of > any transaction or matter discussed herein. >
