There is a index on Solr 4.5 which contains ~50K documents taking ~4Gb on disk. Physical RAM available to JVM is 6Gb (out of total 10Gb on server), OS is 64bit CentOS 5.
One of the applications queries that index several times in a loop, one request sent as soon as the previous one completes with virtually no delay in between but still not simultaneously.
The queries are all the same and fit the following simple pattern:
- q=description:"keyword" OR orders:"keyword" OR catalog:"keyword"
- fl=id,score,name,country
- sort=score desc
- wt=json
- indent=true
- start=0
- rows=100
(all the fields in q
are indexed tokenised text ones)
After a relatively small number of such queries (sometimes after the 3rd one, sometimes after the 5th etc.) received garbage collector on Solr side kicks in because all the memory is busy. That results in several seconds long delay before Solr responds which causes the application sending the request to abort on timeout.
If the application waits between the consequent queries in sends out for about 1 sec, all of them complete quickly and RAM isn't maxed out; but the quicker the queries are sent one after another, the greater are changes the next one would result in a GC triggered and an unwanted timeout.
The same index (built from the same data by the same application) is absolutely fine with the same usage pattern on the older version of Solr (1.4).
Increasing the cache sizes in solrconfig.xml
doesn't seem to have much effect, but reducing rows
parameter to 10 from 100 makes the timeout less likely, while not entirely impossible. queryResultWindowSize
in the config is set to default 20.
I guess there might be more than one reason for the observed behaviour and I have given not enough details. If so, what do I need to change or profile to narrow it down from here?