We used to have one large index - then moved to 10 shards (7 million docs each) - parallel search across all shards, and we get better performance that way. We use a 40 core box with 128GB ram. We do a lot of faceting so maybe that is why since facets can be built in parallel on different threads/cores. We also have indexes on fast local disks (6 15K RPM disks using raid stripes).
On May 14, 2012, at 10:42 AM, Michael Della Bitta wrote: > Hi, all, > > I've been running into murmurs about this idea elsewhere: > > http://stackoverflow.com/questions/8698762/run-multiple-big-solr-shard-instances-on-one-physical-machine > > http://java.dzone.com/articles/optimizing-solr-or-how-7x-your?mz=33057-solr_lucene > > Michael > > On Mon, May 14, 2012 at 10:29 AM, Otis Gospodnetic > <otis_gospodne...@yahoo.com> wrote: >> Hi Kuli, >> >> As long as there are enough CPUs with spare cycles and disk IO is not a >> bottleneck, this works faster. This was 12+ months ago. >> >> Otis >> ---- >> Performance Monitoring for Solr / ElasticSearch / HBase - >> http://sematext.com/spm >> >> >> >>> ________________________________ >>> From: Michael Kuhlmann <k...@solarier.de> >>> To: solr-user@lucene.apache.org >>> Sent: Monday, May 14, 2012 10:21 AM >>> Subject: Re: Solr Shards multi core slower then single big core >>> >>> Am 14.05.2012 16:18, schrieb Otis Gospodnetic: >>>> Hi Kuli, >>>> >>>> In a client engagement, I did see this (N shards on 1 beefy box with lots >>>> of RAM and CPU cores) be faster than 1 big index. >>>> >>> >>> I want to believe you, but I also want to understand. Can you explain >>> why? And did this only happen for single requests, or even under heavy load? >>> >>> Greetings, >>> Kuli >>> >>> >>>
