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]
