Re: Performance "dead-zone" due to garbage collection

[Lance Norskog <go...@gmail.com>]

Sorting creates a large array with "roughly" an entry for every document in
the index. If it is not on an 'integer' field it takes even more memory. If
you do a sorted request and then don't sort for a while, that will drop the
sort structures and trigger a giant GC.

We went through some serious craziness with sorting.

On Fri, Jan 30, 2009 at 3:54 PM, wojtekpia <wo...@hotmail.com> wrote:

>
> I profiled our application, and GC is definitely the problem. The IBM JVM
> didn't change much. I'm currently looking into ways of reducing my memory
> footprint.
>
> --
> View this message in context:
> http://www.nabble.com/Performance-%22dead-zone%22-due-to-garbage-collection-tp21588427p21758001.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
>


-- 
Lance Norskog
goksron@gmail.com
650-922-8831 (US)

Re: Performance "dead-zone" due to garbage collection

[wojtekpia <wo...@hotmail.com>]

I tried sorting using a function query instead of the Lucene sort and found
no change in performance. I wonder if Lance's results are related to
something specific to his deployment?
-- 
View this message in context: http://www.nabble.com/Performance-%22dead-zone%22-due-to-garbage-collection-tp21588427p21922851.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Performance "dead-zone" due to garbage collection

[wojtekpia <wo...@hotmail.com>]

I've been able to reduce these GC outages by:

1) Optimizing my schema. This reduced my index size by more than 50%
2) Smaller cache sizes. I started with filterCache, documentCache &
queryCache sizes of ~10,000. They're now at ~500
3) Reduce heap allocation. I started at 27 GB, now I'm 'only' allocating 8
GB
4) Update to trunk (was using Dec 2/08 code, now using Jan 26/09)

I still see outages due to garbage collection every ~10 minutes, but they
last ~2 seconds (instead of 20+ seconds). Note that my throughput dropped
from ~30 hits/second to ~23 hits/second. Luckily, I'm still hitting my
performance requirements, so I'm able to accept that.

Thanks for the tips!


Wojtek



yonik wrote:
> 
> On Tue, Feb 3, 2009 at 11:58 AM, wojtekpia <wo...@hotmail.com> wrote:
>> I noticed your wiki post about sorting with a function query instead of
>> the
>> Lucene sort mechanism. Did you see a significantly reduced memory
>> footprint
>> by doing this?
> 
> FunctionQuery derives field values from the FieldCache... so it would
> use the same amount of memory as sorting.
> 
> -Yonik
> 
> 

-- 
View this message in context: http://www.nabble.com/Performance-%22dead-zone%22-due-to-garbage-collection-tp21588427p21922773.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Performance "dead-zone" due to garbage collection

[Yonik Seeley <ys...@gmail.com>]

On Tue, Feb 3, 2009 at 11:58 AM, wojtekpia <wo...@hotmail.com> wrote:
> I noticed your wiki post about sorting with a function query instead of the
> Lucene sort mechanism. Did you see a significantly reduced memory footprint
> by doing this?

FunctionQuery derives field values from the FieldCache... so it would
use the same amount of memory as sorting.

-Yonik

Re: Performance "dead-zone" due to garbage collection

[wojtekpia <wo...@hotmail.com>]

I noticed your wiki post about sorting with a function query instead of the
Lucene sort mechanism. Did you see a significantly reduced memory footprint
by doing this? Did you reduce the number of fields you allowed users to sort
by?


Lance Norskog-2 wrote:
> 
> Sorting creates a large array with "roughly" an entry for every document
> in
> the index. If it is not on an 'integer' field it takes even more memory.
> If
> you do a sorted request and then don't sort for a while, that will drop
> the
> sort structures and trigger a giant GC.
> 
> We went through some serious craziness with sorting.
> 

-- 
View this message in context: http://www.nabble.com/Performance-%22dead-zone%22-due-to-garbage-collection-tp21588427p21814038.html
Sent from the Solr - User mailing list archive at Nabble.com.