Maybe you've been looking at it but one thing that I didn't see on a fast scan was that maybe the commit bit is the problem. When you commit, eventually the segments will be merged and a new searcher will be opened (this is true even if you're NOT optimizing). So you're effectively committing every 1-2 seconds, creating many segments which get merged, but more importantly opening new searchers (which you are getting since you pasted the message: Overlapping onDeckSearchers=2).
You could pinpoint this by NOT committing explicitly, just set your autocommit parameters (or specify commitWithin in your indexing program, which is preferred). Try setting it at a minute or so and see if your problem goes away perhaps? The NRT stuff happens on soft commits, so you have that option to have the documents immediately available for search. Best Erick On Mon, Oct 22, 2012 at 10:44 AM, Dotan Cohen <dotanco...@gmail.com> wrote: > I've got a script writing ~50 documents to Solr at a time, then > commiting. Each of these documents is no longer than 1 KiB of text, > some much less. Usually the write-and-commit will take 1-2 seconds or > less, but sometimes it can go over 60 seconds. > > During a recent time of over-60-second write-and-commits, I saw that > the server did not look overloaded: > > $ uptime > 14:36:46 up 19:20, 1 user, load average: 1.08, 1.16, 1.16 > $ free -m > total used free shared buffers cached > Mem: 14980 2091 12889 0 233 1243 > -/+ buffers/cache: 613 14366 > Swap: 0 0 0 > > Other than Solr, nothing is running on this machine other than stock > Ubuntu Server services (no Apache, no MySQL). The machine is running > on an Extra Large Amazon EC2 instance, with a virtual 4-core 2.4 GHz > Xeon processor and ~16 GiB of RAM. The solr home is on a mounted EBS > volume. > > What might make some queries take so long, while others perform fine? > > Thanks. > > > -- > Dotan Cohen > > http://gibberish.co.il > http://what-is-what.com
