Your best bet is MMapDirectoryFactory, you can come very close to the performance of the RAMDirectory. Unfortunatelly this setup with Master_on_disk->Slaves_in_ram type of setup is not possible using solr.
We are moving our architecture to solr at the moment, and this is one of "missings" we have to somehow figure out. The problem is that MMap works fine on average, but it also has quirks regarding upper quntiles of the responses. If you are using RAMDirectory, you do not need to be afraid that occasionally slow IO will kill performance for some of your requests. This happens with MMAP, and not all that rare, depending on your usage pattern (high update/commit rate for example). I repeat, RAMDirectory is not to beat when it comes to reduction of the IO-caused "outliers". We removed some 90% of the slowest response times by using RAMDirectory instead of MMap... Depending on what you want to optimize, MMap can work just fine for you, and has some nice properties, eg. you do not need to tune gc() as much as if you manage bigger heap (RAMDirectory...) But, imo, it would make sense to have some possibility to do it in solr. On Mon, Jun 27, 2011 at 10:50 AM, Shalin Shekhar Mangar <shalinman...@gmail.com> wrote: > On Mon, Jun 27, 2011 at 12:49 PM, nipunb <ni...@walmartlabs.com> wrote: >> I found a similar post - >> http://lucene.472066.n3.nabble.com/Problems-with-RAMDirectory-in-Solr-td1575223.html >> It mentions that Java based replication might work (This is what I have >> used, but didn't work for me) > > Solr Replication does not work with non-file directory implementations. > > -- > Regards, > Shalin Shekhar Mangar. >
