Hm, I can't quite tell from here, but that is just a warning, so it's not super problematic at this point. Could it be that one of your other caches (query cache) is large and lots of items are copied on searcher flip?
Could it be that your JVM doesn't have large or free enough enough heap? Can you tell if lots of GCing happens during the searcher flip? Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Cloude Porteus <clo...@instructables.com> > To: solr-user@lucene.apache.org > Sent: Wednesday, March 25, 2009 1:06:51 AM > Subject: Snapinstaller + Overlapping onDeckSearchers Problems > > We have been running our solr slaves without autowarming our new searchers > for a long time, but that was causing us 50-75 requests in 20+ seconds > timeframe after every update on the slaves. I have turned on autowarming and > that has fixed our slow response times, but I'm running into occasional > Overlapping onDeckSearchers. > > We have replication setup and are using the snapinstaller script every 10 > minutes: > > /home/solr/bin/snappuller -M util01 -P 18984 -D /home/solr/write/data -S > /home/solr/logs -d /home/solr/read/data -u instruct; > /home/solr/bin/snapinstaller -M util01 -S /home/solr/write/logs -d > /home/solr/read/data -u instruct > > Here's what a successful update/commit log looks like: > > [14:13:02.510] start > commit(optimize=false,waitFlush=false,waitSearcher=true) > [14:13:02.522] Opening searc...@e9b4bb main > [14:13:02.524] end_commit_flush > [14:13:02.525] autowarming searc...@e9b4bb main from searc...@159e6e8 main > [14:13:02.525] > filterCache{lookups=1809739,hits=1766607,hitratio=0.97,inserts=43211,evictions=0, > size=43154,cumulative_lookups=1809739,cumulative_hits=1766607,cumulative_hitratio=0.97,cumulative_inserts=43211,cumulative_evictions=0} > -- > [14:15:42.372] {commit=} 0 159964 > [14:15:42.373] /update 0 159964 > > Here's what a unsuccessful update/commit log looks like, where the /update > took too long and we started another commit: > > [21:03:03.829] start > commit(optimize=false,waitFlush=false,waitSearcher=true) > [21:03:03.836] Opening searc...@b2f2d6 main > [21:03:03.836] end_commit_flush > [21:03:03.836] autowarming searc...@b2f2d6 main from searc...@103c520 main > [21:03:03.836] > filterCache{lookups=1062196,hits=1062160,hitratio=0.99,inserts=49144,evictions=0,size=48353,cumulative_lookups=259485564,cumulative_hits=259426904,cumulative_hitratio=0.99,cumulative_inserts=68467,cumulative_evictions=0} > -- > [21:23:04.794] start > commit(optimize=false,waitFlush=false,waitSearcher=true) > [21:23:04.794] PERFORMANCE WARNING: Overlapping onDeckSearchers=2 > [21:23:04.802] Opening searc...@f11bc main > [21:23:04.802] end_commit_flush > -- > [21:24:55.987] {commit=} 0 1312158 > [21:24:55.987] /update 0 1312158 > > > I don't understand why this sometimes takes two minutes between the start > commit & /update and sometimes takes 20 minutes? One of our caches has about > ~40,000 items, but I can't imagine it taking 20 minutes to autowarm a > searcher. > > It would be super handy if the Snapinstaller script would wait until the > previous one was done before starting a new one, but I'm not sure how to > make that happen. > > Thanks for any help with this. > > best, > cloude > > -- > VP of Product Development > Instructables.com > > http://www.instructables.com/member/lebowski
