We do not create readers on our own, that part is done/managed by searcher 
manager. Not sure if they are garbage collected.

What do you mean by indices ?

No, we are not using NoMergePolicy. Default merge policy is used.


Thanks

Rahul

________________________________
From: Adrien Grand <jpou...@gmail.com>
Sent: Wednesday, October 12, 2016 8:22:01 PM
To: Rahul Chandwani; java-user@lucene.apache.org
Subject: Re: Default LRUQueryCache causing OOO exception

After readers are released, are they also free to be garbage collected or
is something holding references to them?
How many indices do you have? Are you using something like the
NoMergePolicy?

Le mer. 12 oct. 2016 à 16:35, Rahul Chandwani <rchandw...@egain.com> a
écrit :

> Hi Adrien,
>
> Every acquire() call is followed by release() call.
>
> ------------------------------
> *From:* Adrien Grand <jpou...@gmail.com>
> *Sent:* Wednesday, October 12, 2016 7:55:58 PM
> *To:* Rahul Chandwani; java-user@lucene.apache.org
>
> *Subject:* Re: Default LRUQueryCache causing OOO exception
> Hi Rahul,
>
> The most likely cause to your problem is that your are leaking IndexReader
> instances. You say you are using SearcherManager, could you check that
> there is a call to release matching every call to acquire?
>
> Le mer. 12 oct. 2016 à 15:02, Rahul Chandwani <rchandw...@egain.com> a
> écrit :
>
> Hi Adrien,
>
> Total number of instances of CompressingStoredFieldsReader = 76,808
> occupying 760 MB heap.
> Total number of instances of SegmentCoreReaders = 38,099 occupying 368 MB
> heap.
>
> Thanks
>
> -----Original Message-----
> From: Adrien Grand [mailto:jpou...@gmail.com <jpou...@gmail.com>]
> Sent: Wednesday, October 12, 2016 12:51 PM
> To: java-user@lucene.apache.org
> Subject: Re: Default LRUQueryCache causing OOO exception
>
>
> Hi Rahul,
>
> High memory from both these classes is unexpected. I am wondering that
> maybe your application does not close index readers when it doesn't need
> them anymore? Another possibility would be that you are dealing with lots
> of IndexReader instances in the same JVM. Are you able to count how many
> instance of CompressingStoredFieldReader were present in the heap?
>
>
> Le mer. 12 oct. 2016 à 09:08, Rahul Chandwani <rchandw...@egain.com> a
> écrit :
>
> > Hello,
> >
> >
> > We are using lucene 5.5.2 for search .
> >
> > We are getting out of memory exception as default LRUQueryCache is
> > occupying more much more than default 32 MB memory.
> >
> > Searcher Manager is used here to get an instance of index searcher to
> > perform search. Default lru query cache and default query cache policy
> > (UsageTrackingQueryCachingPolicy) is used.
> >
> > Maximum memory usage/size is 3 GB for our application.
> >
> > Observation from heap dump:
> >
> > 1. Lucene Codecs CompressingStoredFieldReader objects has consumed ~
> > 727 MB of heap
> >
> > 2. Lucene LRUQueryCache objects has consumed ~ 380 MB of heap. Cache
> > instance is holding up large number of SegmentCoreReaders instances in
> Map.
> >
> >
> > Request you to please guide us.
> >
> >
> > Thanks
> >
> > Rahul
> >
> > ___ Watch an eGain Customer Service Transformation<
> > https://www.youtube.com/watch?v=dEwdFfWoyuE> Success Story
> >
> ___ Watch an eGain Customer Service Transformation
> <https://www.youtube.com/watch?v=dEwdFfWoyuE> Success Story
>
> ___ Watch an eGain Customer Service Transformation
> <https://www.youtube.com/watch?v=dEwdFfWoyuE> Success Story
>
___ Watch an eGain Customer Service 
Transformation<https://www.youtube.com/watch?v=dEwdFfWoyuE> Success Story

Reply via email to