Hi Luis, First to ans you questions,
-Do you index at the same time as users launches queries to twitter index? Yes, currently I am using the same server for indexing and querying due to lack of resources to extent to another server. -Are you using the autocommit option? No, I am committing on approximately 50,000 documents and optimizing once a day. I am using the fq parameter during faceting, since all my queries are datetime bound and max and min auto_id bound. Eg, fq=createdOnGMT[Date1 TO Date2]&fq=id:[id1 TO id2]&facet=true&facet.field.. Regards, Rohit Mobile: +91-9901768202 About Me: http://about.me/rohitg -----Original Message----- From: Luis Cappa Banda [mailto:luisca...@gmail.com] Sent: 17 September 2011 03:38 To: solr-user@lucene.apache.org Subject: Re: Out of memory Hello. Facet queries are slower than others specially when you are working with a 69G index. I would like to know more about the context where occurs the Out of memory exception: is it during an indexation? Do you index at the same time as users launches queries to twitter index? Are you using the autocommit option? If yes, which is your configuration of number of documents buffered or time elapsed to do next commit? By the way, I think that using more servers/indexes with the shards option to launch distributed queries won´t solve the problem. In my opinion it will continue as slow as the present, or even more. Try to check what kind of query you are launching while faceting. I mean that it´s not the same to query with an *"q=*:* and then facet=true&facet.field=whatever"* as *"q=field1:value+AND+field2:value...&facet=true&facet.field=whatever". *I recommend you to check again the query and to test it usingcaching and fq parameters in it. Probably you´ll get better Qtime results. Luis Cappa.
