Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4DE5407C.1010209@jhu.edu>
Date: Tue, 31 May 2011 15:24:44 -0400
From: Jonathan Rochkind <rochkind@jhu.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: solr-user@lucene.apache.org
Subject: Re: Using multiple CPUs for a single document base?
References: <BE072919-C8D9-408C-99E9-7B886A1AEE61@collab.net>
 <4DE5338B.9050707@jhu.edu> <C48B8816-26BA-4090-97F1-6CC3C5E769A4@collab.net>
In-Reply-To: <C48B8816-26BA-4090-97F1-6CC3C5E769A4@collab.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yep, that could be it.

You certainly don't get _great_ concurrency support 'for free' in Java, 
concurrent programming is still tricky. Parts of Solr are surely better 
at it than others.

The one place I'd be shocked was just with multiple concurrent queries, 
if those weren't helped by multi-CPUs.   Multi CPUs won't neccesarily 
speed up any single query, they should just speed up the overall 
situation under heavy load.  Which has been my observation. And it may 
be that multi-CPU's don't speed up add/commit much, as you possibly have 
observed.

I do all my 'adds' to a seperate Solr index, and then replicate to a 
slave that actually serves queries. My 'master' that I do my adds to is 
actually on the very same server -- but I run it in an entirely 
different java container, in part to minimize any chance that it will 
end up competing for threads/CPUs with the slave serving queries, the OS 
level alone should ('should', famous last word)  balance it to a 
different cpu core. (Of course, there's still only so much total CPU 
avail on the machine).

On 5/31/2011 2:53 PM, Jack Repenning wrote:
> On May 31, 2011, at 11:29 AM, Jonathan Rochkind wrote:
>
>> I kind of think you should get multi-CPU use 'for free' as a Java app too.
> Ah, probably experimental error? If I apply a stress load consisting only of queries, I get automatic multi-core use as expected. I could see where indexing new dox could tend toward synchronization and uniprocessing. Perhaps my original test load was too add-centric, does that make sense?
>
> -==-
> Jack Repenning
> Technologist
> Codesion Business Unit
> CollabNet, Inc.
> 8000 Marina Boulevard, Suite 600
> Brisbane, California 94005
> office: +1 650.228.2562
> twitter: http://twitter.com/jrep
>
>
>
>
>
>
>
>
>