On 2/6/2014 4:00 AM, Shawn Heisey wrote:
I would not recommend it, but if you know for sure that your
infrastructure can handle it, then you should be able to optimize them
all at once by sending parallel optimize requests with distrib=false
directly to the Solr cores that hold the shard replicas
On 2/5/2014 11:20 PM, Sesha Sendhil Subramanian wrote:
> I am running solr cloud with 10 shards. I do a batch indexing once everyday
> and once indexing is done I call optimize.
>
> I see that optimize happens on each shard one at a time and not in
> parallel. Is it possible for the optimize to ha
: Subject: "optimize" index : impact on performance
: References: <1375381044900-4082026.p...@n3.nabble.com>
: In-Reply-To: <1375381044900-4082026.p...@n3.nabble.com>
https://people.apache.org/~hossman/#threadhijack
Thread Hijacking on Mailing Lists
When starting a new discussion on a mailing li
Hi,
We already did some benchmarks during optimize and we haven't noticed a big
impact on overall performance of search. The benchmarks' results were almost
the same with vs. without running optimization. We have enough free RAM for the
two OS disk caches during optimize (15 GB represents the
On 8/2/2013 8:13 AM, Anca Kopetz wrote:
Then we optimized the index to 1 segment / 0 deleted docs and we got
+40% of QPS compared to the previous test.
Therefore we thought of optimizing the index every two hours, as our
index is evolving due to frequent commits (every 30 minutes) and thus
the p
no, you didn't miss anything. The comment at Lucen Revolution was more
along the lines that optimize didn't actually improve much #absent# deletes.
Plus, on a significant size corpus, the doc frequencies won't changed that
much by deleting documents, but that's a case-by-case thing
Best
Erick
On
what you can try maxSegments=2 or more as a 'partial' optimize:
"If the index is so large that optimizes are taking longer than desired
or using more disk space during optimization than you can spare,
consider adding the maxSegments parameter to the optimize command. In
the XML message, this
Huh? That's something new for me. Optmize removed documents that have been
flagged for deletion. For relevancy it's important those are removed because
document frequencies are not updated for deletes.
Did i miss something?
> For what it's worth, the Solr class instructor at the Lucene Revoluti
For what it's worth, the Solr class instructor at the Lucene Revolution
conference recommended *against* optimizing, and instead suggested to just
let the merge factor do it's job.
On Thu, Nov 4, 2010 at 2:55 PM, Shawn Heisey wrote:
> On 11/4/2010 7:22 AM, stockiii wrote:
>
>> how can i start an
On 11/4/2010 7:22 AM, stockiii wrote:
how can i start an optimize by using DIH, but NOT after an delta- or
full-import ?
I'm not aware of a way to do this with DIH, though there might be
something I'm not aware of. You can do it with an HTTP POST. Here's
how to do it with curl:
/usr/bin/c
Ha
Now I feel stupid !!
I had a misspell in the data path and you were correct.
Can I ask Erik was the command correct though ?
Thank you
Lee
On 2 Mar 2010, at 13:54, Erick Erickson wrote:
> My very first guess would be that you're removing an index that isn't
> the one your SOLR configurati
My very first guess would be that you're removing an index that isn't
the one your SOLR configuration points at.
Second guess would be that your browser is caching the results of
your first query and not going to SOLR at all. Stranger things have
happened .
Third guess is you've mis-identified th
e.apache.org
Subject: Re: Optimize index
While we're on the subject of optimizing: Are there any benefits to
optimizing an index before merging it into another index?
Thanks,
Stu
-Original Message-
From: Mike Klaas <[EMAIL PROTECTED]>
Sent: Wed, August 8, 2007 5:16 pm
To: solr
<[EMAIL PROTECTED]>
> Sent: Wed, August 8, 2007 5:16 pm
> To: solr-user@lucene.apache.org
> Subject: Re: Optimize index
>
> On 8-Aug-07, at 2:09 PM, Jae Joo wrote:
>
> > How about standformat optimizion?
> > Jae
>
> Optimized indexes are always faster
While we're on the subject of optimizing: Are there any benefits to optimizing
an index before merging it into another index?
Thanks,
Stu
-Original Message-
From: Mike Klaas <[EMAIL PROTECTED]>
Sent: Wed, August 8, 2007 5:16 pm
To: solr-user@lucene.apache.org
Subject: R
On 8-Aug-07, at 2:09 PM, Jae Joo wrote:
How about standformat optimizion?
Jae
Optimized indexes are always faster at query time that their non-
optimized counterparts. Sometimes significantly so.
-Mike
How about standformat optimizion?
Jae
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik
Seeley
Sent: Wednesday, August 08, 2007 5:07 PM
To: solr-user@lucene.apache.org
Subject: Re: Optimize index
On 8/8/07, Jae Joo <[EMAIL PROTECTED]> wrote:
&g
On 8/8/07, Jae Joo <[EMAIL PROTECTED]> wrote:
> So, is compound index faster at query time?
Slower (but very slightly). A little less concurrency under heavy load.
-Yonik
So, is compound index faster at query time?
Jae
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik
Seeley
Sent: Wednesday, August 08, 2007 4:32 PM
To: solr-user@lucene.apache.org
Subject: Re: Optimize index
On 8/8/07, Jae Joo <[EMAIL PROTECTED]>
On 8/8/07, Jae Joo <[EMAIL PROTECTED]> wrote:
> Does anyone know how to optimize the index and what the difference between
> compound format and stand format?
Compound index format squishes almost all the files of a segment into
a single file. It's slower at index time.
-Yonik
You optimize by sending a command to the SOLR update
handler. I'm not sure about the different index formats though..
++
| Matthew Runo
| Zappos Development
| [EMAIL PROTECTED]
| 702-943-7833
+-
21 matches
Mail list logo
