Hi Shawn, Please check that link http://wiki.apache.org/solr/SimpleFacetParameters#facet.method there is something mentioned in facet.method wiki
*The default value is fc (except for BoolField which uses enum) since it tends to use less memory and is faster then the enumeration method when a field has many unique terms in the index.* So can you explain how enum is faster than default. Also we are currently using the solr 4.2 does that support this facet.method=enum, if not then which version should we pick. We are planning to move to SolrCloud with the version solr 4.7.1, so does this 14 GB of RAM will be sufficient? or should we increase it? With Regards Aman Tandon On Thu, May 1, 2014 at 8:20 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 4/30/2014 5:53 PM, Aman Tandon wrote: > > Shawn -> Yes we have some plans to move to SolrCloud, Our total index > size > > is 40GB with 11M of Docs, Available RAM 32GB, Allowed heap space for solr > > is 14GB, the GC tuning parameters using in our server > > is -XX:+UseConcMarkSweepGC -XX:+PrintGCApplicationStoppedTime > > -XX:+PrintGCDetails -XX:+PrintGCTimeStamps. > > This means that you have about 18GB of RAM left over to cache a 40GB > index. That's less than 50 percent. Every index is different, but this > is in the ballpark of where performance problems begin. If you had 48GB > of RAM, your performance (not counting possible GC problems) would > likely be very good. 64GB would be ideal. > > Your only GC tuning is switching the collector to CMS. This won't be > enough. When I had a config like this and heap of only 8GB, I was > seeing GC pauses of 10 to 12 seconds. > > http://wiki.apache.org/solr/ShawnHeisey#GC_Tuning > > One question: Do you really need 14GB of heap? One of my servers has a > total of 65GB of index (54 million docs) with a 7GB heap and 64GB of > RAM. Currently I don't use facets, though. When I do, they will be > enum. If you switch all your facets to enum, your heap requirements may > go down. Decreasing the heap size will make more memory available for > index caching. > > Thanks, > Shawn > >
