nsidered.
> >
> > I am trying to find the winning combination.
> > Tirthankar
> > -Original Message-
> > From: Erick Erickson [mailto:erickerick...@gmail.com]
> > Sent: Friday, September 16, 2011 7:46 AM
> > To: solr-user@lucene.apache.org
> > Subject: Re:
ilto:erickerick...@gmail.com]
> Sent: Friday, September 16, 2011 7:46 AM
> To: solr-user@lucene.apache.org
> Subject: Re: NRT and commit behavior
>
> Uhm, you're putting a lot of index into not very much memory. I really think
> you're going to have to shard your index ac
]
Sent: Friday, September 16, 2011 7:46 AM
To: solr-user@lucene.apache.org
Subject: Re: NRT and commit behavior
Uhm, you're putting a lot of index into not very much memory. I really think
you're going to have to shard your index across several machines to get past
this probl
che"
> size="512"
> initialSize="512"
> autowarmCount="512"/>
>
> -Original Message-
> From: Tirthankar Chatterjee [mailto:tchatter...@commvault.com]
> Sent: Wednesday, September 14, 2011 7:31 AM
> To: solr-u
Chatterjee [mailto:tchatter...@commvault.com]
Sent: Wednesday, September 14, 2011 7:31 AM
To: solr-user@lucene.apache.org
Subject: RE: NRT and commit behavior
Erick,
Here is the answer to your questions:
Our index is 267 GB
We are not optimizing...
No we have not profiled yet to check the bottleneck
and Tomcat
-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Sunday, September 11, 2011 11:37 AM
To: solr-user@lucene.apache.org
Subject: Re: NRT and commit behavior
Hmm, OK. You might want to look at the non-cached filter query stuff, it's
quite recent
as false and found that inside the code it hard
> coded to be true. Is there any specific reason. Can we change that value to
> honor what is being passed.
>
> Thanks,
> Tirthankar
>
> -Original Message-
> From: Erick Erickson [mailto:erickerick...@gmail.com]
> Sent: T
---
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Thursday, September 01, 2011 8:38 AM
To: solr-user@lucene.apache.org
Subject: Re: NRT and commit behavior
Hmm, I'm guessing a bit here, but using an invalid query doesn't sound very
safe, but I suppose it *might* be OK.
kar
>
> -Original Message-
> From: Jonathan Rochkind [mailto:rochk...@jhu.edu]
> Sent: Monday, July 18, 2011 11:38 AM
> To: solr-user@lucene.apache.org; yo...@lucidimagination.com
> Subject: Re: NRT and commit behavior
>
> In practice, in my experience at least, a ve
er. Are we doing
something wrong here?
Thanks,
Tirthankar
-Original Message-
From: Jonathan Rochkind [mailto:rochk...@jhu.edu]
Sent: Monday, July 18, 2011 11:38 AM
To: solr-user@lucene.apache.org; yo...@lucidimagination.com
Subject: Re: NRT and commit behavior
In practice, in my experienc
From one of the users of NRT, their system was freezing with commits at
about 1.5 million docs due to the frequency of commits but with NRT
(Solr with RankingAlgorithm) update document performance and a commit
interval of about 15 mins they no longer have the freeze problem.
Regards,
- Nagen
I've written a blog post on some of the recent improvements that explains
things a bit:
http://www.lucidimagination.com/blog/2011/07/11/benchmarking-the-new-solr-%E2%80%98near-realtime%E2%80%99-improvements/
On Jul 18, 2011, at 10:53 AM, Nicholas Chase wrote:
> Very glad to hear that NRT is fin
In practice, in my experience at least, a very 'expensive' commit can
still slow down searches significantly, I think just due to CPU (or
i/o?) starvation. Not sure anything can be done about that. That's my
experience in Solr 1.4.1, but since searches have always been async with
commits, it p
On Mon, Jul 18, 2011 at 10:53 AM, Nicholas Chase wrote:
> Very glad to hear that NRT is finally here! But my question is this: will
> things still come to a standstill during a commit?
New updates can now proceed in parallel with a commit, and
searches have always been completely asynchronous w.
14 matches
Mail list logo
