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 a
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
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 commitoptimize
once a day at 3:00AM. It takes 15-20 minutes, but I have several millions
daily updates...
Is there
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
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
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
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
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
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.
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,
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
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 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 your log
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
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
Hi Uwe,
5 minutes is not slow; commit can't be realtime... I do
commitoptimize 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?
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
seconds.
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
18 matches
Mail list logo
