views:

186

answers:

1

I am facing scalability issues designing a new Solr cluster and I need to master to be able to handle a relatively high rate of updates with almost no reads - they can be done via slaves.

My existing Solr instance is occupying a huge amount of RAM, in fact it started swapping at only 4.5mil docs. I am interested in making the footprint as little as possible in RAM, even if it affects search performance.

So, which Solr config values can I tweak in order to accomplish this?

Thank you.

+2  A: 

It's hard to say without knowing the specifics of your enviroment (like the schema, custom indexers, queryfunctions etc...) and whats a huge amount of ram? but you could start by

setting filterCache, queryResultCache and documentCache to 0 in solrconfig.xml. This will severely impact the performance of queries executed in SOLR.

set compression to true TextField and StrField types that you store. Then set compressThreshold to a low integer value. This will decrease the size of the documents at the cost of increased CPU usage. (see http://wiki.apache.org/solr/SchemaXml#head-73cdcd26354f1e31c6268b365023f21ee8796613 for more details

turn off all autowarming queries and don't do any read queries

make sure you commit often enough

obviously these are all things to do on the master not on the slaves.

olle
Thank you. These are excellent suggestions. The machine running Solr currently is 32bit so the VM doesn't want to start with anything more than 2400m max heap. Solr quickly eats up all of it and commits and optimizes start hitting the Heap out of memory errors. The schema has been slimmed down to almost nothing - about 15 fields, only one of them stored (int) - the rest are just indexed. I will play around with all of your suggestions - they all look spot on. Keep em coming!
Artem Russakovskii
I actually don't store any data - just the indexes, in which case compression is not useful, right?
Artem Russakovskii
Correct. Are you using special or allot of different analysers?
olle
I'm using almost no analyzers. For now.
Artem Russakovskii