Hi Andre, Wow that is astonishing! I will definitely also try that out! Just set the facet method on a per field basis for the less used sparse facet fields eh? Thanks for the tip.
Thanks Robi -----Original Message----- From: Andre Bois-Crettez [mailto:andre.b...@kelkoo.com] Sent: Tuesday, June 18, 2013 3:03 AM To: solr-user@lucene.apache.org Subject: Re: yet another optimize question Recently we had steadily increasing memory usage and OOM due to facets on dynamic fields. The default facet.method=fc need to build a large array of maxdocs ints for each field (a fieldCache or fieldValueCahe entry), whether it is sparsely populated or not. Once you have reduced your number of maxDocs with the merge policy, it can be interesting to try facet.method=enum for all the sparsely populated dynamic fields. Despite what is said in the wiki, in our case the performance was similar to facet.method=fc, however the JVM heap usage went down from about 20GB to 4GB. André On 06/17/2013 08:21 PM, Petersen, Robert wrote: > Also some time ago I made all our caches small enough to keep us from getting > OOMs while still having a good hit rate. Our index has about 50 fields > which are mostly int IDs and there are some dynamic fields also. These > dynamic fields can be used for custom faceting. We have some standard facets > we always facet on and other dynamic facets which are only used if the query > is filtering on a particular category. There are hundreds of these fields > but since they are only for a small subset of the overall index they are very > sparsely populated with regard to the overall index. -- André Bois-Crettez Search technology, Kelkoo http://www.kelkoo.com/ Kelkoo SAS Société par Actions Simplifiée Au capital de € 4.168.964,30 Siège social : 8, rue du Sentier 75002 Paris 425 093 069 RCS Paris Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'en avertir l'expéditeur.