lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: A model for predicting indexing memory costs?
Date Tue, 10 Mar 2009 16:53:17 GMT

On Mar 10, 2009, at 7:55 AM, mark harwood wrote:

>
>>> It does not indefinitely hang,
>
> I guess I just need to be more patient.
> Thanks for the GC settings. I don't currently have the luxury of "15  
> other" processors but this will definitely be of use in other  
> environments.

It is also, usually helpful to look at what is causing all the garbage  
in the first place.   I've seen those kind of major collection pauses  
(even on a multicore machine using parallel GC) induced when switching  
over IndexReaders and having to load FieldCaches (for sorting,  
etc.).    Simply put, the Eden storage and the "old" storage can get  
filled up faster than even the parallel collector can keep up with.  
Taking the time to analyze the needs for the memory almost always  
solves the problem versus spending copious amounts of time tweaking GC  
parameters that are under documented and also contain non-obvious  
interactions between parameters.  Plus, it undoubtedly plays to your  
strength as a search designer, not a JVM GC expert.

Mark M has a post on helpful tools at: http://www.lucidimagination.com/blog/2009/02/09/investigating-oom-and-other-jvm-issues/

  and I've found http://java.sun.com/docs/hotspot/gc5.0/ 
gc_tuning_5.html to be really useful at times.

Just my two cents,
Grant


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message