Hi Shalin, Thanks for the clarifications.
Could you please explain a bit more on how the new searcher can double the memory ? 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. Also I am assuming that like commit optimization also happens during update/delete query only. Regards, Sourav ________________________________________ From: Shalin Shekhar Mangar [EMAIL PROTECTED] Sent: Tuesday, November 25, 2008 6:40 AM To: solr-user@lucene.apache.org Cc: souravm Subject: Re: Sorting and JVM heap size .... On Tue, Nov 25, 2008 at 7:49 AM, souravm <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote: 3. Another case is - if there are 2 search requests concurrently hitting the server, each with sorting on the same 20 character date field, then also it would need 2x2GB memory. So if I know that I need to support at least 4 concurrent search requests, I need to start the JVM at least with 8 GB heap size. This is a misunderstanding. Yonik said "searchers", not "searches". A single searcher handles all live search requests. When a commit/optimize happens, a new searcher is created, it's caches are auto-warmed and then swapped with the live searcher. It may be a bit more complicated under the hoods, but that's pretty much how it works. Considering that after commits and during auto-warming, another searcher might have been created which will have another field cache for each field you are sorting on, you'll need double the memory. The number of searchers can be controlled through the "maxWarmingSearchers" parameter in solrconfig.xml -- Regards, Shalin Shekhar Mangar. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***
