On Mon, Oct 6, 2008 at 2:10 PM, Jim Murphy <[EMAIL PROTECTED]> wrote: > We have a farm of several Master-Slave pairs all managing a single very large > "logical" index sharded across the master-slaves. We notice on the slaves, > after an rsync update, as the index is being committed that all queries are > blocked sometimes resulting in unacceptable service times. I'm looking at > ways we can manage these "update burps".
Updates should never block queries. What version of Solr are you using? Is it possible that your indexes are so big, opening a new index in the background causes enough of the old index to be flushed from OS cache, causing big slowdowns? -Yonik > Question #1: Anything obvious I can tweak in the configuration to mitigate > these multi-second blocking updates? Our Indexes are 40GB, 20M documents > each. RSync updates are every 5 minutes several hundred KB per update. > > Question #2: I'm considering setting up each slave with multiple Solr cores. > The 2 indexes per instance would be nearly identical copies but "A" would be > read from while "B" is being updated, then they would swap. I'll have to > figure out how to rsync these 2 indexes properly but if I can get the > commits to happen to the offline index then I suspect my queries could > proceed unblocked. > > Is this the wrong tree to be barking up? Any other thoughts? > > Thanks in advance, > > Jim > > > > -- > View this message in context: > http://www.nabble.com/Index-updates-blocking-readers%3A-To-Multicore-or-not--tp19843098p19843098.html > Sent from the Solr - User mailing list archive at Nabble.com. > >
