right...I was forgetting the 30MB flush by ram is PER writerI'll
make some tests to verify this and fix accordingly...
Thanks!!
On Tue, Dec 16, 2008 at 12:06 PM, Michael McCandless
wrote:
>
> That class is what's used to buffer the added docs in IndexWriter. The heap
> dump seems to indicat
That class is what's used to buffer the added docs in IndexWriter.
The heap dump seems to indicate you've got ~55 MB worth of buffered
docs pending. Since you allow a 30MB RAM buffer for each writer, and
it seems like you allow up to 60 writers to be opened at once, it
seems like in the
I'm no expert on lucene internals, but maybe the posting lists just
happen to be what is around when your program hits the OOM error. It
seems more likely that you are getting OOM because of all the caches
and other stuff you are doing. I suggest giving it more memory or
cache fewer indexes, or t
yes I have tested with up to 512MB, althought I dont have the hprof
dump file of those tests, they also got the OOM. I was just wondering
whether having so many instances of FreqProxTermsWriter$PostingList
around is a clear indicator of something I am not releasing or
something.
javier
On Tue, De
Can you not just give the process some more memory? 128Mb seems very
low for what you are doing.
--
Ian.
On Mon, Dec 15, 2008 at 6:28 PM, jm wrote:
> Hi,
>
> I am having a memory issue with Lucene2.4. I am strating a process
> with 128MB of ram, this process handles incoming request from othe
Hi,
I am having a memory issue with Lucene2.4. I am strating a process
with 128MB of ram, this process handles incoming request from others,
and indexes objects in a number of lucene indexes.
My lucene docs, all have 6 fields:
-one is small: Field.Store.YES, Field.Index.UN_TOKENIZED, Field.TermVe
