Hi
I have now recreated the whole index with new index files and all is back to
normal again. I think something had happend to our old index files.
Many thanks to you who tried to help.
Uwe
On Mon, Oct 6, 2008 at 5:39 PM, Uwe Klosa <[EMAIL PROTECTED]> wrote:
> I already had the chance to setup
I already had the chance to setup a new server for testing. Before deploying
my application I checked my solrconfig against the solrconfig from 1.3. And
removed the deprecated parameters. I started updating the new index. I
ingest 100 documents att a time and then I do a commit(). With 2000 ingeste
It's a live server with many search queries. I will set up a test server
next week or the week after and index the same amount of documents. I will
get back with the results.
Uwe
On Sat, Oct 4, 2008 at 8:18 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 4, 2008 at 11:55 AM, Uwe Klosa
On Sat, Oct 4, 2008 at 11:55 AM, Uwe Klosa <[EMAIL PROTECTED]> wrote:
> A "Opening Server" is always happening directly after "start commit" with no
> delay.
Ah, so it doesn't look like it's the close of the IndexWriter then!
When do you see the "end_commit_flush"?
Could you post everything in you
A "Opening Server" is always happening directly after "start commit" with no
delay. But I can see many {commit=} with QTime around 280.000 (4 and a half
minutes)
One difference I could see to your logging is that I have waitFlush=true.
Could that have this impact?
Uwe
On Sat, Oct 4, 2008 at 4:36
On Sat, Oct 4, 2008 at 9:35 AM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
> So it seems like fsync with ZFS can be very slow?
The other user that appears to have a commit issue is on Win64.
http://www.nabble.com/*Very*-slow-Commit-after-upgrading-to-solr-1.3-td19720792.html#a19720792
-Yonik
On Fri, Oct 3, 2008 at 2:28 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
> Yonik, when Solr commits what does it actually do?
Less than it used to (Solr now uses Lucene to handle deletes).
A solr-level commit closes the IndexWriter, calls some configured
callbacks, opens a new IndexSearcher,
Oh OK, phew. I misunderstood your answer too!
So it seems like fsync with ZFS can be very slow?
Mike
Uwe Klosa wrote:
Oh, you meant index files. I misunderstood your question. Sorry, now
that I
read it again I see what you meant. There are only 136 index files.
So no
problem there.
Uwe
Oh, you meant index files. I misunderstood your question. Sorry, now that I
read it again I see what you meant. There are only 136 index files. So no
problem there.
Uwe
On Sat, Oct 4, 2008 at 1:59 PM, Michael McCandless <
[EMAIL PROTECTED]> wrote:
>
> Yikes! That's way too many files. Have you
Yikes! That's way too many files. Have you changed mergeFactor? Or
implemented a custom DeletionPolicy or MergePolicy?
Or... does anyone know of something else in Solr's configuration that
could lead to such an insane number of files?
Mike
Uwe Klosa wrote:
There are around 35.000 fil
There are around 35.000 files in the index. When I started Indexing 5 weeks
ago with only 2000 documents I did not this issue. I have seen it the first
time with around 10.000 documents.
Before that I have been using the same instance on a Linux machine with up
to 17.000 documents and I haven't se
Hmm OK that seems like a possible explanation then. Still it's spooky
that it's taking 5 minutes. How many files are in the index at the
time you call commit?
I wonder if you were to simply pause for say 30 seconds, before
issuing the commit, whether you'd then see the commit go faster?
Thanks Mike
The use of fsync() might be the answer to my problem, because I have
installed Solr for lack of other possibilities in a zone on Solaris with ZFS
which slows down when many fsync() calls are made. This will be fixed in a
upcoming release of Solaris, but I will move as soon as possible
5 minutes for only one update is slow.
On Fri, Oct 3, 2008 at 8:13 PM, Fuad Efendi <[EMAIL PROTECTED]> wrote:
> Hi Uwe,
>
> 5 minutes is not slow; commit can't be realtime... I do commit&optimize
> once a day at 3:00AM. It takes 15-20 minutes, but I have several millions
> daily updates...
>
>
>
Yonik Seeley wrote:
On Fri, Oct 3, 2008 at 1:56 PM, Uwe Klosa <[EMAIL PROTECTED]> wrote:
I have a big problem with one of my solr instances. A commit can
take up to
5 minutes. This time does not depend on the number of documents
which are
updated. The difference for 1 or 100 updated docume
On Fri, Oct 3, 2008 at 1:56 PM, Uwe Klosa <[EMAIL PROTECTED]> wrote:
> I have a big problem with one of my solr instances. A commit can take up to
> 5 minutes. This time does not depend on the number of documents which are
> updated. The difference for 1 or 100 updated documents is only a few
> sec
Hi Uwe,
5 minutes is not slow; commit can't be realtime... I do
commit&optimize once a day at 3:00AM. It takes 15-20 minutes, but I
have several millions daily updates...
Is there a way to see why commits are slow? Has anyone had the same problem
and what was the solution that solved it?
Similar report with no response yet:
http://www.nabble.com/*Very*-slow-Commit-after-upgrading-to-solr-1.3-td19720792.html#a19720792
Uwe Klosa wrote:
Hi
I have a big problem with one of my solr instances. A commit can take up to
5 minutes. This time does not depend on the number of documents wh
Hi
I have a big problem with one of my solr instances. A commit can take up to
5 minutes. This time does not depend on the number of documents which are
updated. The difference for 1 or 100 updated documents is only a few
seconds. I am running solr on tomcat 5.5 and java 1.6 on Solaris 10 on Sparc
19 matches
Mail list logo
