Hi,
On 07.05.2010 22:47, Chris Hostetter wrote:
so it's the full request time, and would be inclusive of any postCommit
event handlers -- that's important to know. the logs will help clear up
wether the underlying "commit" is really taking up a large amount of time
or if it's some postCommit ev
: The measurement was done outside our Solr client which sends the update
: and then the commit to the handler. I also see the update-URL call in
: the Tomcat Manager taking up that amount of time.
so it's the full request time, and would be inclusive of any postCommit
event handlers -- that's i
The mail servers are often not too friendly with attachments, so people
either inline configs or put them on a server and post the URL.
HTH
Erick
On Wed, May 5, 2010 at 12:06 PM, Markus Fischer wrote:
> Hi,
>
> On 05.05.2010 03:49, Chris Hostetter wrote:
> >
> > : Are you accidentally building
Hi,
On 05.05.2010 03:49, Chris Hostetter wrote:
>
> : Are you accidentally building the spellchecker database on each commit?
> ...
> : > This could also be caused by performing an optimize after the commit, or
> it
> : > could be caused by auto warming the caches, or a combination of both
: Are you accidentally building the spellchecker database on each commit?
...
: > This could also be caused by performing an optimize after the commit, or it
: > could be caused by auto warming the caches, or a combination of both.
The heart of the matter being: it's pretty much impossibl
> From: Markus Fischer [mailto:mar...@fischer.name]
>> Sent: Tuesday, May 04, 2010 6:22 AM
>> To: solr-user@lucene.apache.org
>> Subject: Re: Commit takes 1 to 2 minutes, CPU usage affects other apps
>>
>> On 04.05.2010 11:01, Peter Sturge wrote:
>> > It might b
gt; To: solr-user@lucene.apache.org
> Subject: Re: Commit takes 1 to 2 minutes, CPU usage affects other apps
>
> On 04.05.2010 11:01, Peter Sturge wrote:
> > It might be worth checking the VMWare environment - if you're using
> the
> > VMWare scsi vmdk and it's shared
On 04.05.2010 11:01, Peter Sturge wrote:
It might be worth checking the VMWare environment - if you're using the
VMWare scsi vmdk and it's shared across multiple VMs and there's a lot of
disk contention (i.e. multiple VMs are all busy reading/writing to/from the
same disk channel), this can reall
It might be worth checking the VMWare environment - if you're using the
VMWare scsi vmdk and it's shared across multiple VMs and there's a lot of
disk contention (i.e. multiple VMs are all busy reading/writing to/from the
same disk channel), this can really slow down I/O operations.
On Tue, May 4
Hi,
On 04.05.2010 03:24, Mark Miller wrote:
On 5/3/10 9:06 AM, Markus Fischer wrote:
we recently began having trouble with our Solr 1.4 instance. We've about
850k documents in the index which is about 1.2GB in size; the JVM which
runs tomcat/solr (no other apps are deployed) has been given 2GB.
On 5/3/10 9:06 AM, Markus Fischer wrote:
Hi,
we recently began having trouble with our Solr 1.4 instance. We've about
850k documents in the index which is about 1.2GB in size; the JVM which
runs tomcat/solr (no other apps are deployed) has been given 2GB.
We've a forum and run a process every m
Hi,
we recently began having trouble with our Solr 1.4 instance. We've about
850k documents in the index which is about 1.2GB in size; the JVM which
runs tomcat/solr (no other apps are deployed) has been given 2GB.
We've a forum and run a process every minute which indexes the new
messages.
12 matches
Mail list logo
