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.


-----Original Message-----

From: Adrien Grand [mailto: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

Reply via email to