Thanks Erik.When you mentioned we can't control sorting by _docid_ . So if not client Does that mean solr internally makes such type of queries which includes sort on internal Lucene Id? And for what purpose? Sent from Yahoo Mail on Android On Wed, Aug 5, 2020 at 6:27 PM, Erick Erickson<erickerick...@gmail.com> wrote: A sort on anything can cause an OOM… That said, _all_ fields defined in your Solr schema should have docValues set to true if you sort, group, use function queries or facet on them. What’s happening is the docValues structure is being synthesized at runtime on the heap. In recent Solr releases you can specify uninvertible=true flag to generate exceptions when this is attempted rather than hit an OOM, see: https://lucene.apache.org/solr/guide/8_3/defining-fields.html
You can’t control sorting by _docid_, but if you’re specifying that from the client, it’s almost certainly not doing what you expect. Best, Erick > On Aug 4, 2020, at 10:19 PM, sanjay dutt <sanjaydutt.in...@yahoo.com.INVALID> > wrote: > > Hello, > We were investigating one HEAP DUMP in which FielsCaceImpl has occupied > around 5GB. Upon further investigation, I got to know that > FieldCacheImpl$SortedDocValues occupies 90% of the memory where > FieldCacheImpl$CacheKey is "id". > When I checked the logs I was trying to find any query in which there is any > sort on id field. But instead I find few queries in which we are sorting on > _docid_ lucene internal id. > Can sort on _docid_ cause OOM? > And if I will enable docValues for uniqueKey(id) will that solve my problem? > Regards,SanjaySent from Yahoo Mail on Android
