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] 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
