You must be calling SearcherManager.maybeRefresh periodically, which
does open new NRT readers.

Can you please triple check that you do in fact always release() after
an acquire(), in a finally clause?

You have far far too many CompressingStoredFieldsReader instances in your JVM.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Oct 12, 2016 at 11:16 AM, Rahul Chandwani <rchandw...@egain.com> wrote:
> 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

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

Reply via email to