i wouldnt worry about the index size until you get above a half terabyte or
so. adding doc values and other features means you sacrifice things that
dont matter, like size. memory and ssd's are cheap.
On Wed, Apr 15, 2020 at 1:21 PM Rajdeep Sahoo
wrote:
> Hi all
> We are migrating from solr 4.
e rsync confirm that it has been entirely
> completed.
> >
> > I don't see any transaction not completed that normaly means that the
> indexation is completed. That's why I don't understand the difference.
> >
> > Kind Regards
> >
> > Matthieu
&
e
> colleague who realized the rsync confirm that it has been entirely completed.
>
> I don't see any transaction not completed that normaly means that the
> indexation is completed. That's why I don't understand the difference.
>
> Kind Regards
>
> M
se.io]
Sent: samedi 9 février 2019 16:56
To: solr-user@lucene.apache.org
Subject: Re: Solr Index Size after reindex
Yes, those numbers are different and that should explain the different size. I
think you should be able to find some information in the Alfresco or Solr log.
There must be a reas
* vendredi 8 février 2019 14:54
*To:* solr-user@lucene.apache.org
*Subject:* Re: Solr Index Size after reindex
Hi Mathieu,
what about the docs in the two infrastructures? Do they have the same
numbers (numdocs / maxdocs)? Any meaningful message (error or not) in
log files?
Andrea
On 08/02
9 14:54
To: solr-user@lucene.apache.org
Subject: Re: Solr Index Size after reindex
Hi Mathieu,
what about the docs in the two infrastructures? Do they have the same numbers
(numdocs / maxdocs)? Any meaningful message (error or not) in log files?
Andrea
On 08/02/2019 14:19, Mathieu Menard wrote:
Hi Mathieu,
what about the docs in the two infrastructures? Do they have the same
numbers (numdocs / maxdocs)? Any meaningful message (error or not) in
log files?
Andrea
On 08/02/2019 14:19, Mathieu Menard wrote:
Hello,
I would like to have your point of view about an observation we have
On 4/10/2017 1:57 AM, Himanshu Sachdeva wrote:
> Thanks for your time and quick response. As you said, I changed our
> logging level from SEVERE to INFO and indeed found the performance
> warning *Overlapping onDeckSearchers=2* in the logs. I am considering
> limiting the *maxWarmingSearchers* coun
On Mon, 2017-04-10 at 13:27 +0530, Himanshu Sachdeva wrote:
> Thanks for your time and quick response. As you said, I changed our
> logging level from SEVERE to INFO and indeed found the performance
> warning *Overlapping onDeckSearchers=2* in the logs.
If you only see it occasionally, it is proba
Hi Himanshu,
maxWarmingSearchers would break nothing on production. Whenever you request
solr to open a new searcher, it autowarms the searcher so that it can
utilize caching. After autowarm is complete a new searcher is opened.
The questions you need to adress here are
1. Are you using soft-com
Hi Toke,
Thanks for your time and quick response. As you said, I changed our logging
level from SEVERE to INFO and indeed found the performance warning *Overlapping
onDeckSearchers=2* in the logs. I am considering limiting the
*maxWarmingSearchers* count in configuration but want to be sure that
n
On Thu, 2017-04-06 at 16:30 +0530, Himanshu Sachdeva wrote:
> We monitored the index size for a few days and found that it varies
> widely from 11GB to 43GB.
Lucene/Solr indexes consists of segments, each holding a number of
documents. When a document is deleted, its bytes are not removed
immedia
Did you check if your index still contains 500 docs, or is there more?
Regards,
Edwin
On 12 March 2016 at 22:54, Toke Eskildsen wrote:
> sara hajili wrote:
> > why solr index size become bigger and bigger without adding any new doc?
>
> Solr does not change the index unprovoked. It sounds lik
sara hajili wrote:
> why solr index size become bigger and bigger without adding any new doc?
Solr does not change the index unprovoked. It sounds like your external
document feeding process is still running.
- Toke Eskildsen
Hi I was faced the same problem.
You can get it rectified by allocating specified memory to the jar process
that is running.
java -Xmx1024M -Xms1024M -jar start.jar you can specify the amount of
memory to the process.
--
Thank you,
Vijayant Kumar
Software Engineer
Website Toolbox Inc.
http://w
Solr needs memory allocation for different operations, not for the
index size. It needs X amount of memory for a query, Y amount of
memory for document found by a query, and other things. Sorting needs
memory for the number of documents. Faceting needs memory for the
number of unique values in a fi
>I tried to merge the 15 indexes again, and I found out that the new merged
>index (without opitmization) size was about 351 GB , but when I optimize it
>the size return back to 411 GB, Why?
Just as a sample, IOT in Oracle...
Ok, just in a kids-lang, what 'optimization' means? It means that Ma
On Tue, Aug 25, 2009 at 3:30 PM, engy.ali wrote:
>
> Summary
> ===
>
> I had about 120,000 object of total size 71.2 GB, those objects are already
> indexed using Lucene. The index size is about 111 GB.
>
> I tried to use solr 1.4 nightly build to index the same collection. I
> divided
On Sat, Aug 29, 2009 at 7:09 AM, engy.ali wrote:
> I thought that optimization would decrease or at least be equal to the same
> index size before optimization
Some index structures like norms are non-sparse. Index one unique
field with norms and there is a byte allocated for every document in
th
Hi,
Thanks for your reply.
I will work on your suggestion for using only one solr instance.
I tried to merge the 15 indexes again, and I found out that the new merged
index (without opitmization) size was about 351 GB , but when I optimize it
the size return back to 411 GB, Why?
I thought tha
Hi,
Can you try to use single SOLR instance with heavy RAM (so that
ramBufferSizeMB=8192 for instance) and mergeFactor=10? Single SOLR instance
is fast enough (> 100 client threads of Tomcat; configurable) - I usually
prefer single instance for single "writable" box with heavy RAM allocation
and g
Slightly different index sizes (even optimized) are normal - a same
document may get different internal docids in different runs. I don't
know why the number of terms are slight different.
On Fri, Apr 3, 2009 at 7:21 PM, Jun Rao wrote:
>
>
> Hi,
>
> We built a Solr index on a set of documents a
Hi Marshall,
There is nothing such built-in, but you can easily build simple external tools
to do this.
You can check the disk space used by the index (du)
You can check the total number of docs in the index (via Luke request handler)
You'll still have to have some mechanism of retrieving the ol
23 matches
Mail list logo
