Thanks Erick, I shall have a look into the blogs. Thanks & Regards, Kranti K Parisa http://www.linkedin.com/in/krantiparisa
On Wed, Jul 31, 2013 at 7:21 AM, Erick Erickson <[email protected]>wrote: > By and large, you should not second-guess the JVM. I really think you're > chasing something that won't have measurable impact, just wasted effort. > In general, the GC settings that come with your java are pretty good and > you really should leave them alone until you have measurements > indicating that GC is a problem. > > But if you insist, here are some interesting blogs: > > http://www.lucidimagination.com/blog/2011/03/27/garbage-collection-bootcamp-1-0/ > > And one for the G1 collector: > http://wiki.apache.org/solr/ShawnHeisey#GC_Tuning > > > > On Tue, Jul 30, 2013 at 2:19 PM, Kranti Parisa <[email protected]> > wrote: > > Agree with you, we do have unique identifiers for the 5 min windows in > terms > > of window start time. Just wanted to tell GC to clean up un-used caches > > instead of having them on the JVM. So that we may use JVM/RAM for serving > > more queries as it would have more free memory. > > > > Do you have any suggestions for the common JVM settings while using Solr > (of > > course the values depends on the actual use case) something similar to > > > http://jprante.github.io/2012/11/28/Elasticsearch-Java-Virtual-Machine-settings-explained.html > > ? > > > > Thanks & Regards, > > Kranti K Parisa > > http://www.linkedin.com/in/krantiparisa > > > > > > > > On Sun, Jul 28, 2013 at 6:42 PM, Erick Erickson <[email protected] > > > > wrote: > >> > >> I'd certainly do that before trying to have a custom cache policy. > >> Measure, > >> _then_ fix. If you have your autowarm parameters set up, when your > >> searchers come up you'll get good responses on your queries. > >> > >> Of course that will put some load on the machine, but find out whether > >> the load is noticeable before you make the switch. > >> > >> Or be really cheap. For the 5 minute interval, tack on some kind of > >> meaningless > >> value to the FQ that doesn't change the effect. Then change that every 5 > >> minutes > >> and your old fq cache entries won't be re-used and will age out as time > >> passes. > >> > >> FWIW, > >> Erick > >> > >> On Sun, Jul 28, 2013 at 12:37 PM, Kranti Parisa (JIRA) <[email protected] > > > >> wrote: > >> > > >> > [ > >> > > https://issues.apache.org/jira/browse/SOLR-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13721993#comment-13721993 > >> > ] > >> > > >> > Kranti Parisa commented on SOLR-5080: > >> > ------------------------------------- > >> > > >> > Sure, new searcher will invalidate the caches. But the use cases are > we > >> > don't want to expire the other caches than FilterCache. And for us the > >> > filters are time bounded, for every 5 minutes the availability > changes. I am > >> > trying to set up a multi core environment and use joins (with FQ). > >> > Replication happens for every 30 min. If we open a new searcher for > every 5 > >> > min, then all the other caches are also invalidated and during > runtime it > >> > may cost us to rebuild those caches. Instead of that, the idea is to > have a > >> > facility to configure the FilterCaches with 5 min expiration policy > on one > >> > of the cores (where availability changes every 5 min) so that we can > >> > maintain the JVM sizes which will also be an imp factor on high load. > >> > > >> > So, you suggest to open new searcher which will invalid all the caches > >> > on the specific core? > >> > > >> >> Ability to Configure Expirable Caches (use Google Collections - > >> >> MapMaker/CacheBuilder for SolrCache) > >> >> > >> >> > ---------------------------------------------------------------------------------------------------- > >> >> > >> >> Key: SOLR-5080 > >> >> URL: https://issues.apache.org/jira/browse/SOLR-5080 > >> >> Project: Solr > >> >> Issue Type: New Feature > >> >> Reporter: Kranti Parisa > >> >> > >> >> We should be able to configure the expirable caches, especially for > >> >> filterCaches. In some cases, the filterCaches are not valid beyond > certain > >> >> time (example 5 minutes). > >> >> Google collections has MapMaker/CacheBuilder which does allow > >> >> expiration > >> >> > >> >> > http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/MapMaker.html > >> >> > >> >> > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/cache/CacheBuilder.html > >> >> SolrCache, LRUCache etc can be implemented with MapMaker or > >> >> CacheBuilder > >> > > >> > -- > >> > This message is automatically generated by JIRA. > >> > If you think it was sent incorrectly, please contact your JIRA > >> > administrators > >> > For more information on JIRA, see: > >> > http://www.atlassian.com/software/jira > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
