Petersen, Robert [robert.peter...@mail.rakuten.com] wrote:
We actually have hundreds of facet-able fields, but most are specialized
and are only faceted upon if the user has drilled into the particular category
to which they are applicable and so they are only indexed for products
in those
Subject: RE: yet another optimize question
Petersen, Robert [robert.peter...@mail.rakuten.com] wrote:
We actually have hundreds of facet-able fields, but most are specialized
and are only faceted upon if the user has drilled into the particular
category
to which they are applicable and so
facet fields eh?
Thanks for the tip.
Thanks
Robi
-Original Message-
From: Andre Bois-Crettez [mailto:andre.b...@kelkoo.com]
Sent: Tuesday, June 18, 2013 3:03 AM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
Recently we had steadily increasing memory usage
[mailto:wun...@wunderwood.org]
Sent: Tuesday, June 18, 2013 6:57 PM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
Your query cache is far too small. Most of the default caches are too small.
We run with 10K entries and get a hit rate around 0.30 across four servers
@lucene.apache.org
Subject: Re: yet another optimize question
Hi Robi,
This goes against the original problem of getting OOMEs, but it looks like
each of your Solr caches could be a little bigger if you want to eliminate
evictions, with the query results one possibly not being worth keeping if
you can't
: Wednesday, June 19, 2013 10:50 AM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
I generally run with an 8GB heap for a system that does no faceting. 32GB does
seem rather large, but you really should have room for bigger caches.
The Akamai cache will reduce your hit rate
Recently we had steadily increasing memory usage and OOM due to facets
on dynamic fields.
The default facet.method=fc need to build a large array of maxdocs ints
for each field (a fieldCache or fieldValueCahe entry), whether it is
sparsely populated or not.
Once you have reduced your number of
...@gmail.com]
Sent: Saturday, June 15, 2013 5:52 AM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
Hi Robi,
I'm going to guess you are seeing smaller heap also simply because you
restarted the JVM recently (hm, you don't say you restarted, maybe I'm making
this up
, 2013 6:36 PM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
Yes, in one of the example solrconfig.xml files this is right above the merge
factor definition.
Otis
--
Solr ElasticSearch Support -- http://sematext.com/
On Mon, Jun 17, 2013 at 8:00 PM, Petersen
, June 18, 2013 3:03 AM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
Recently we had steadily increasing memory usage and OOM due to facets on
dynamic fields.
The default facet.method=fc need to build a large array of maxdocs ints for
each field (a fieldCache
[mailto:otis.gospodne...@gmail.com]
Sent: Saturday, June 15, 2013 5:52 AM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
Hi Robi,
I'm going to guess you are seeing smaller heap also simply because you
restarted the JVM recently (hm, you don't say you restarted
cumulative_inserts : 351485
cumulative_evictions : 276308
-Original Message-
From: Otis Gospodnetic [mailto:otis.gospodne...@gmail.com]
Sent: Saturday, June 15, 2013 5:52 AM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
Hi Robi,
I'm going to guess you
cumulative_inserts : 351485
cumulative_evictions : 276308
-Original Message-
From: Otis Gospodnetic [mailto:otis.gospodne...@gmail.com]
Sent: Saturday, June 15, 2013 5:52 AM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
Hi Robi,
I'm going to guess you
12:29 PM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
The key figures are numdocs vs maxdocs. Maxdocs-numdocs is the number of
deleted docs in your index.
This is a 3.6 system you say. But has it been upgraded? I've seen folks who've
upgraded from 1.4 or 3.0/3.1
@lucene.apache.org
Subject: Re: yet another optimize question
The key figures are numdocs vs maxdocs. Maxdocs-numdocs is the number of
deleted docs in your index.
This is a 3.6 system you say. But has it been upgraded? I've seen folks
who've upgraded from 1.4 or 3.0/3.1 over time, keeping the old
...@gmail.com]
Sent: Saturday, June 15, 2013 5:52 AM
To: solr-user@lucene.apache.org
Subject: Re: yet another optimize question
Hi Robi,
I'm going to guess you are seeing smaller heap also simply because you
restarted the JVM recently (hm, you don't say you restarted, maybe I'm making
this up
Hi Robi,
I'm going to guess you are seeing smaller heap also simply because you
restarted the JVM recently (hm, you don't say you restarted, maybe I'm
making this up). If you are indeed indexing continuously then you
shouldn't optimize. Lucene will merge segments itself. Lower
mergeFactor will
Hi guys,
We're on solr 3.6.1 and I've read the discussions about whether to optimize or
not to optimize. I decided to try not optimizing our index as was recommended.
We have a little over 15 million docs in our biggest index and a 32gb heap for
our jvm. So without the optimizes the index
18 matches
Mail list logo
