On Tue, Nov 25, 2008 at 9:37 PM, souravm <[EMAIL PROTECTED]> wrote: > > Could you please explain a bit more on how the new searcher can double the > memory ? >
Take a look at slide 13 of Yonik's presentation available at http://people.apache.org/~yonik/ApacheConEU2006/Solr.ppt Each searcher in Solr maintains various caches for performance reasons. When a new one is created, its caches are empty. If one exposes this searcher to live requests, response times can be very long because a lot of disk accesses may be needed. Therefore, Solr warms the new searcher's caches by re-executing queries whose results had been cached on the old searcher's cache. If you sort on fields, then the new searcher will create its own FieldCache for each field you sort. At this time, both the old and the new searcher will have their field caches. > > Based on your explanation, when a new set of documents gets committed a new > searcher is created. So what I understand is whenever a update/delete query > and search query run in parallel then only this type of situation may occur. > Not during updates/deletes, but when you issue an commit or optimize command. > > Also I am assuming that like commit optimization also happens during > update/delete query only. Commit or Optimize have to be called by you explicitly. -- Regards, Shalin Shekhar Mangar.
