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 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
> ingested documents the commit time is 1-3 seconds. I'll get back tomorrow
> with more results.
>
> Uwe
>
>
>
> On Sun, Oct 5, 2008 at 2:52 PM, Uwe Klosa <[EMAIL PROTECTED]> wrote:
>
>> 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 <[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 between when the commit begins
>>> and when it ends?
>>> Is this a live server (is query traffic continuing to come in while
>>> the commit is happening?) If so, it would be interesting to see (and
>>> easier to debug) if it happened on a server with no query traffic.
>>>
>>> > 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?
>>>
>>> These parameters (waitFlush/waitSearcher) won't affect how long it
>>> takes to get the new searcher registered, but does affect at what
>>> point control is returned to the caller (and hence when you see the
>>> response). If waitSearcher==false, then you see the response before
>>> searcher warming, otherwise it blocks until after. waitFlush==false
>>> is not currently supported (it will always act as true), so your
>>> change of that doesn't matter.
>>>
>>> -Yonik
>>>
>>
>>
>
