Re: Very Slow Commits After Solr Index Optimization

[Shawn Heisey]

On 9/22/2016 3:27 PM, vsolakhian wrote:
> This is not the cause of the problem though. The disk cache is
> important for queries and overall performance during optimization, but
> once it is done, everything should go back to "normal" (whatever that
> normal is). In our case it is the SOFT COMMIT (that opens a new
> Searcher) that takes 10 times longer AFTER the index was optimized and
> deleted records were removed (and index size went down to 60 GB).

It's difficult to say without hard numbers, and that is complicated by
my very limited understanding of how HDFS gets cached.

"Normal" is achieved only when relevant data is in the disk cache. 
Which will most likely not be the case after an optimize, unless you
have enough caching memory for both the before and after index to fit at
the same time.  Similar performance issues are likely to occur right
after a server reboot.

A soft commit opens a new searcher.  When a new searcher is opened, the
*Solr* caches (which are entirely different from the disk cache) look at
their autowarmCount settings.  Each cache gathers the top N queries
contained in the cache, up to the autowarmCount number, and proceeds to
execute the those queries on the index to create a brand new cache for
the new searcher.  The new searcher is not put into place until the
warming is done.  The commit will not finish until the new searcher is
online.

If the info sitting in the OS disk cache when the warming queries happen
is not useful for fast queries, then those queries will be very slow,
which makes the commit take longer.

For better commit times, reduce autowarmCount on your Solr caches.  This
will make it more likely that users will notice slow queries, though.

Good Solr performance with large indexes requires a LOT of memory.  The
amount required is usually very surprising to admins.

Thanks,
Shawn

Re: Very Slow Commits After Solr Index Optimization

[vsolakhian]

Thanks again, Shawn.

You are completely right about the use of disk cache and the special note
regarding the optimize operation in Solr wiki.

This is not the cause of the problem though. The disk cache is important for
queries and overall performance during optimization, but once it is done,
everything should go back to "normal" (whatever that normal is). In our case
it is the SOFT COMMIT (that opens a new Searcher) that takes 10 times longer
AFTER the index was optimized and deleted records were removed (and index
size went down to 60 GB).

Regards,

Victor



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Very-Slow-Commits-After-Solr-Index-Optimization-tp4297022p4297588.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Very Slow Commits After Solr Index Optimization

[Shawn Heisey]

On 9/22/2016 1:01 PM, vsolakhian wrote:
> Our index is in HDFS, but we did not change any configuration after we
> deleted 35% of records and optimized.
>
> The relatively slow commit (soft commit and warming up took 1.5 minutes) is
> OK for our use case (adding hundreds of thousands and even millions of
> records and then committing).
>
> The question is why it takes much longer after optimization, when disk
> caches, network and other configuration remained the same and the index is
> smaller?

When you optimize an index down to one segment, you are reading one
entire copy of the index and creating a second copy of the index.  This
is going to greatly affect the data that is in the disk cache.

Presumably you do not have enough caching memory to hold anywhere near
the entire 300GB index.  Memory sizes that large are possible, but not
common.  With HDFS, I think the amount of memory used for caching is
configurable.  I do not know if both HDFS clients and servers can do
caching, or if that's just a server-side option.  With a 300GB index,
150 to 250GB of memory should be available for caching if you want to
have stellar performance.  If you can get the entire 300GB to fit, then
you'd nearly be guaranteed good performance.

Assuming I'm right about the amount of caching memory available relative
to the index size, when the optimize is finished, chances are very good
that the particular data sitting in the disk cache is completely useless
for queries, so the first few warming and user queries will need to
actually read the *disk*, and put different data in the cache.  When
enough queries have been processed, eventually the disk cache will be
populated with enough relevant data that subsequent queries will be fast.

If there are other programs or Solr indexes competing for the same
caching memory, then the problem might be even worse.

You might want to refrain from optimizing indexes this large, at least
on a frequent basis, and just rely on normal index merging to handle
your deletes.

Optimizing is a special case when it comes to cache memory, and for
that, you need even more than in the general case.  There's a special
note about optimizes here:

https://wiki.apache.org/solr/SolrPerformanceProblems#OS_Disk_Cache

Thanks,
Shawn

Re: Very Slow Commits After Solr Index Optimization

[vsolakhian]

Hi Shawn,

Thank you for response. Everything you said is correct in general.

Our index is in HDFS, but we did not change any configuration after we
deleted 35% of records and optimized.

The relatively slow commit (soft commit and warming up took 1.5 minutes) is
OK for our use case (adding hundreds of thousands and even millions of
records and then committing).

The question is why it takes much longer after optimization, when disk
caches, network and other configuration remained the same and the index is
smaller?

Thanks,

Victor



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Very-Slow-Commits-After-Solr-Index-Optimization-tp4297022p4297548.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Very Slow Commits After Solr Index Optimization

[Shawn Heisey]

On 9/20/2016 4:13 PM, vsolakhian wrote:
> We knew that optimization is not a good idea and it was discussed in forums
> that it should be completely removed from API and Solr Admin, but discussing
> is one  thing and doing it is another. To make the story short, we tried to
> optimize through Solr API to remove deleted records:
>
> URL=http://:8983/solr//update
> curl "$URL?optimize=true=18=true"
>
> and all three replicas of the collection were merged to 18 segments and Solr
> Admin was showing "Optimized: Yes (green)", but the deleted records were not
> removed (which is an inconsistency with Solr Admin or a bug in the API).

Very likely the deleted documents were contained in segments that were
NOT merged, and made up the total final segment count of 18. An optimize
will only guarantee all deleted documents are gone if it optimizes to
ONE segment, which is what the "Optimize" button in the admin UI does.

> Finally, because people usually trust features fuond in UI (even if official
> documentation is not found, see
> https://cwiki.apache.org/confluence/display/solr/Using+the+Solr+Administration+User+Interface),
> the "Optimize Now" button in Solr Admin was pressed and it removed all
> deleted records and made the collection look very good (in UI). Here is the
> problem:
>
> 1. The index was reduced to one large (60 GB) segment (some people's opinion
> is that it is good, but I doubt).
> 2. Our use case includes batch updates and then a soft commit (after which
> the user sees results). Commit operation that was taking about 1.5 minutes
> now takes from 12 to 25 minutes.
>
> Overall performance of our application is severely degraded.
>
> I am not going to talk about how confusing Solr optimization is,  but I am
> asking if anyone knows *what caused slowness of the commit operation after
> optimization*. If the issue is having a large segment, then how is it
> possible to split this segment into smaller ones (without sharding)?

Best guess is that actual disk I/O was required after the optimization,
because the important parts of the index were no longer in the OS disk
cache.  For good performance, Solr requires that data be cached and
immediately available -- disks are slow.  Performance would likely
increase as additional queries were made until it returned to normal.

If your indexes are in a filesystem local to the Solr server, then you
probably need more memory in the Solr server (not allocated to the Java
heap).  If they are in a remote filesystem (HDFS, NFS, etc) then the
remote filesystem device/server might need more memory and/or
configuration adjustments.  The speed of the network might be a factor
with remote filesystems.

Side note:  A commit that takes 1.5 minutes is ALREADY very slow. 
Commits should normally take seconds.  Well-tuned NRT environments will
probably have commit times well below one second.

Here's some specific info on slow commits:

http://wiki.apache.org/solr/SolrPerformanceProblems#Slow_commits

Thanks,
Shawn

Very Slow Commits After Solr Index Optimization

[vsolakhian]

We are using Solr Cloud 4.10.3-cdh5.4.5 that is part of CLoudera CDH 5.4.5.
Our collection (one shard with three replicas) became really big and we
decided to delete some old records to improve performance (tests in staging
environment have shown that after reaching 500 million records the index
becomes very slow and Solr is less responsive). After deleting about 100
million records (out of 260 mil.), they were still shown as "Deleted Docs'
in Solr Admin Statistics page.  This page was showing 'Optimized: No (red)'
and 'Current: No (red)'. Theoretically, having 100 million deleted (but not
removed) records would be a performance issue and also, people tend to have
clean picture.

Information found in Solr forums was that the only way to removed deleted
records is to optimize the index.

We knew that optimization is not a good idea and it was discussed in forums
that it should be completely removed from API and Solr Admin, but discussing
is one  thing and doing it is another. To make the story short, we tried to
optimize through Solr API to remove deleted records:

URL=http://:8983/solr//update
curl "$URL?optimize=true=18=true"

and all three replicas of the collection were merged to 18 segments and Solr
Admin was showing "Optimized: Yes (green)", but the deleted records were not
removed (which is an inconsistency with Solr Admin or a bug in the API).
Finally, because people usually trust features fuond in UI (even if official
documentation is not found, see
https://cwiki.apache.org/confluence/display/solr/Using+the+Solr+Administration+User+Interface),
the "Optimize Now" button in Solr Admin was pressed and it removed all
deleted records and made the collection look very good (in UI). Here is the
problem:

1. The index was reduced to one large (60 GB) segment (some people's opinion
is that it is good, but I doubt).
2. Our use case includes batch updates and then a soft commit (after which
the user sees results). Commit operation that was taking about 1.5 minutes
now takes from 12 to 25 minutes.

Overall performance of our application is severely degraded.

I am not going to talk about how confusing Solr optimization is,  but I am
asking if anyone knows *what caused slowness of the commit operation after
optimization*. If the issue is having a large segment, then how is it
possible to split this segment into smaller ones (without sharding)?

Thanks,

Victor



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Very-Slow-Commits-After-Solr-Index-Optimization-tp4297022.html
Sent from the Solr - User mailing list archive at Nabble.com.

RE: Slow commits

[Adam Neal [Extranet]]

I have also tried it with the fields just indexed and not stored, the 
performance is the same so I doubt it is related to stored field compression.

I can file a JIRA, unfortunately I wont be able to provide example files for 
this system but I will try and reproduce it with some test data and include 
that. 

From: Yonik Seeley [ysee...@gmail.com]
Sent: 22 February 2016 15:43
To: solr-user@lucene.apache.org
Subject: Re: Slow commits


On Mon, Feb 22, 2016 at 10:22 AM, Adam Neal [Extranet] <an...@mass.co.uk> wrote:
> Highest count is fairly equal between string and text. They are not indexed 
> but stored and no docvalues used

Ah, that's a big clue...
I wonder if it's related to stored fields compression.  In Solr 5.5.
there is a way to tune compression, but the default is already
BEST_SPEED.
I don't know if an easy way to turn compression off to see if that is
the culprit.

Whatever the reasons, this seems to be a large performance regression,
and it's not clear if it's expected or not.
Could you file a JIRA issue for this?

-Yonik

> 
> From: Yonik Seeley [ysee...@gmail.com]
> Sent: 22 February 2016 14:40
> To: solr-user@lucene.apache.org
> Subject: Re: Slow commits
>
>
> What are the types of the fields with the highest count?  I assume
> they are indexed.  Are they stored, and do they have docValues?
>
> -Yonik
>
>
> On Mon, Feb 22, 2016 at 4:37 AM, Adam Neal [Extranet] <an...@mass.co.uk> 
> wrote:
>> Well I got the numbers wrong, there are actually around 66000 fields on the 
>> index. I have restructured the index and there are now around 1500 fiields. 
>> This has resulted in the commit taking 34 seconds which is acceptable for my 
>> usage however it is still significantly slower than the 4.10.2 commit on the 
>> original 66000 fields which was around 1 second.
>> 
>> From: Adam Neal [Extranet] [an...@mass.co.uk]
>> Sent: 19 February 2016 17:43
>> To: solr-user@lucene.apache.org
>> Subject: RE: Slow commits
>>
>> I'm out of the office now so I don't have the numbers to hand but from 
>> memory I think there are probably around 800-1000 fields or so. I will 
>> confirm on Monday.
>>
>> If i have time over the weekend I will try and recreate the problem at home 
>> and see if I can post up a sample.
>> ____
>> From: Yonik Seeley [ysee...@gmail.com]
>> Sent: 19 February 2016 16:25
>> To: solr-user@lucene.apache.org
>> Subject: Re: Slow commits
>>
>> On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk> 
>> wrote:
>>> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
>>> commits on one of my cores. The core in question is relatively small (56k 
>>> docs) and the issue only shows when commiting after a number of deletes, 
>>> commiting after additions is fine. As an example commiting after deleting 
>>> approximately 10% of the documents takes around 25mins. The same test on 
>>> the 4.10.2 instance takes around 1 second.
>>>
>>> I have done some investigation and the problem appears to be caused by 
>>> having dynamic fields, the core in question has a large number, performing 
>>> the same operation on this core with the dynamic fields removed sees a big 
>>> improvement on the performance with the commit taking 11 seconds (still not 
>>> quite on a par with 4.10.2).
>>
>> Dynamic fields is a Solr schema concept, and does not translate to any
>> differences in Lucene.
>> You may be hitting something due to a large number of fields (at the
>> lucene level, each field name is a different field).  How many
>> different fields (i.e. fieldnames) do you have across the entire
>> index?
>>
>> -Yonik
>>
>> #
>>
>> This E-mail is the property of Mass Consultants Ltd. It is confidential and 
>> intended only for the use of the addressee or with its permission.  Use by 
>> anyone else for any purpose is prohibited.  If you are not the addressee, 
>> you should not use, disclose, copy or distribute this e-mail and should 
>> notify us of receipt immediately by return e-mail to the address where the 
>> e-mail originated.
>>
>> This E-mail may not have been sent through a secure system and accordingly 
>> (i) its contents should not be relied upon by any person without independent 
>> verification from Mass Consultants Ltd and (ii) it is the responsibility of 
>> th

Re: Slow commits

[Yonik Seeley]

On Mon, Feb 22, 2016 at 10:22 AM, Adam Neal [Extranet] <an...@mass.co.uk> wrote:
> Highest count is fairly equal between string and text. They are not indexed 
> but stored and no docvalues used

Ah, that's a big clue...
I wonder if it's related to stored fields compression.  In Solr 5.5.
there is a way to tune compression, but the default is already
BEST_SPEED.
I don't know if an easy way to turn compression off to see if that is
the culprit.

Whatever the reasons, this seems to be a large performance regression,
and it's not clear if it's expected or not.
Could you file a JIRA issue for this?

-Yonik

> 
> From: Yonik Seeley [ysee...@gmail.com]
> Sent: 22 February 2016 14:40
> To: solr-user@lucene.apache.org
> Subject: Re: Slow commits
>
>
> What are the types of the fields with the highest count?  I assume
> they are indexed.  Are they stored, and do they have docValues?
>
> -Yonik
>
>
> On Mon, Feb 22, 2016 at 4:37 AM, Adam Neal [Extranet] <an...@mass.co.uk> 
> wrote:
>> Well I got the numbers wrong, there are actually around 66000 fields on the 
>> index. I have restructured the index and there are now around 1500 fiields. 
>> This has resulted in the commit taking 34 seconds which is acceptable for my 
>> usage however it is still significantly slower than the 4.10.2 commit on the 
>> original 66000 fields which was around 1 second.
>> 
>> From: Adam Neal [Extranet] [an...@mass.co.uk]
>> Sent: 19 February 2016 17:43
>> To: solr-user@lucene.apache.org
>> Subject: RE: Slow commits
>>
>> I'm out of the office now so I don't have the numbers to hand but from 
>> memory I think there are probably around 800-1000 fields or so. I will 
>> confirm on Monday.
>>
>> If i have time over the weekend I will try and recreate the problem at home 
>> and see if I can post up a sample.
>> ____
>> From: Yonik Seeley [ysee...@gmail.com]
>> Sent: 19 February 2016 16:25
>> To: solr-user@lucene.apache.org
>> Subject: Re: Slow commits
>>
>> On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk> 
>> wrote:
>>> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
>>> commits on one of my cores. The core in question is relatively small (56k 
>>> docs) and the issue only shows when commiting after a number of deletes, 
>>> commiting after additions is fine. As an example commiting after deleting 
>>> approximately 10% of the documents takes around 25mins. The same test on 
>>> the 4.10.2 instance takes around 1 second.
>>>
>>> I have done some investigation and the problem appears to be caused by 
>>> having dynamic fields, the core in question has a large number, performing 
>>> the same operation on this core with the dynamic fields removed sees a big 
>>> improvement on the performance with the commit taking 11 seconds (still not 
>>> quite on a par with 4.10.2).
>>
>> Dynamic fields is a Solr schema concept, and does not translate to any
>> differences in Lucene.
>> You may be hitting something due to a large number of fields (at the
>> lucene level, each field name is a different field).  How many
>> different fields (i.e. fieldnames) do you have across the entire
>> index?
>>
>> -Yonik
>>
>> #
>>
>> This E-mail is the property of Mass Consultants Ltd. It is confidential and 
>> intended only for the use of the addressee or with its permission.  Use by 
>> anyone else for any purpose is prohibited.  If you are not the addressee, 
>> you should not use, disclose, copy or distribute this e-mail and should 
>> notify us of receipt immediately by return e-mail to the address where the 
>> e-mail originated.
>>
>> This E-mail may not have been sent through a secure system and accordingly 
>> (i) its contents should not be relied upon by any person without independent 
>> verification from Mass Consultants Ltd and (ii) it is the responsibility of 
>> the recipient to ensure that the onward transmission, opening or use of this 
>> message and any attachments will not adversely affect its systems or data. 
>> No responsibility is accepted by Mass Consultants Ltd in this regard.
>>
>> Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may be 
>> monitored by systems or persons other than the addressee, for the purposes 
>> of ascertaining whether the communication complie

RE: Slow commits

[Adam Neal [Extranet]]

Highest count is fairly equal between string and text. They are not indexed but 
stored and no docvalues used

From: Yonik Seeley [ysee...@gmail.com]
Sent: 22 February 2016 14:40
To: solr-user@lucene.apache.org
Subject: Re: Slow commits


What are the types of the fields with the highest count?  I assume
they are indexed.  Are they stored, and do they have docValues?

-Yonik


On Mon, Feb 22, 2016 at 4:37 AM, Adam Neal [Extranet] <an...@mass.co.uk> wrote:
> Well I got the numbers wrong, there are actually around 66000 fields on the 
> index. I have restructured the index and there are now around 1500 fiields. 
> This has resulted in the commit taking 34 seconds which is acceptable for my 
> usage however it is still significantly slower than the 4.10.2 commit on the 
> original 66000 fields which was around 1 second.
> 
> From: Adam Neal [Extranet] [an...@mass.co.uk]
> Sent: 19 February 2016 17:43
> To: solr-user@lucene.apache.org
> Subject: RE: Slow commits
>
> I'm out of the office now so I don't have the numbers to hand but from memory 
> I think there are probably around 800-1000 fields or so. I will confirm on 
> Monday.
>
> If i have time over the weekend I will try and recreate the problem at home 
> and see if I can post up a sample.
> 
> From: Yonik Seeley [ysee...@gmail.com]
> Sent: 19 February 2016 16:25
> To: solr-user@lucene.apache.org
> Subject: Re: Slow commits
>
> On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk> 
> wrote:
>> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
>> commits on one of my cores. The core in question is relatively small (56k 
>> docs) and the issue only shows when commiting after a number of deletes, 
>> commiting after additions is fine. As an example commiting after deleting 
>> approximately 10% of the documents takes around 25mins. The same test on the 
>> 4.10.2 instance takes around 1 second.
>>
>> I have done some investigation and the problem appears to be caused by 
>> having dynamic fields, the core in question has a large number, performing 
>> the same operation on this core with the dynamic fields removed sees a big 
>> improvement on the performance with the commit taking 11 seconds (still not 
>> quite on a par with 4.10.2).
>
> Dynamic fields is a Solr schema concept, and does not translate to any
> differences in Lucene.
> You may be hitting something due to a large number of fields (at the
> lucene level, each field name is a different field).  How many
> different fields (i.e. fieldnames) do you have across the entire
> index?
>
> -Yonik
>
> #
>
> This E-mail is the property of Mass Consultants Ltd. It is confidential and 
> intended only for the use of the addressee or with its permission.  Use by 
> anyone else for any purpose is prohibited.  If you are not the addressee, you 
> should not use, disclose, copy or distribute this e-mail and should notify us 
> of receipt immediately by return e-mail to the address where the e-mail 
> originated.
>
> This E-mail may not have been sent through a secure system and accordingly 
> (i) its contents should not be relied upon by any person without independent 
> verification from Mass Consultants Ltd and (ii) it is the responsibility of 
> the recipient to ensure that the onward transmission, opening or use of this 
> message and any attachments will not adversely affect its systems or data. No 
> responsibility is accepted by Mass Consultants Ltd in this regard.
>
> Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may be 
> monitored by systems or persons other than the addressee, for the purposes of 
> ascertaining whether the communication complies with the law and Mass 
> Consultants Ltd's policies.
>
> Mass Consultants Ltd is registered in England No. 1705804, Enterprise House, 
> Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom. Tel: +44 
> (0) 1480 222600.
>
> #
>
> #
>
> This E-mail is the property of Mass Consultants Ltd. It is confidential and 
> intended only for the use of the addressee or with its permission.  Use by 
> anyone else for any purpose is prohibited.  If you are not the addressee, you 
> should not use, disclose, copy or distribute this e-mail and should notify us 
> of receipt immediately by return e-mail to the address where the e-mail 
>

Re: Slow commits

[Yonik Seeley]

What are the types of the fields with the highest count?  I assume
they are indexed.  Are they stored, and do they have docValues?

-Yonik


On Mon, Feb 22, 2016 at 4:37 AM, Adam Neal [Extranet] <an...@mass.co.uk> wrote:
> Well I got the numbers wrong, there are actually around 66000 fields on the 
> index. I have restructured the index and there are now around 1500 fiields. 
> This has resulted in the commit taking 34 seconds which is acceptable for my 
> usage however it is still significantly slower than the 4.10.2 commit on the 
> original 66000 fields which was around 1 second.
> 
> From: Adam Neal [Extranet] [an...@mass.co.uk]
> Sent: 19 February 2016 17:43
> To: solr-user@lucene.apache.org
> Subject: RE: Slow commits
>
> I'm out of the office now so I don't have the numbers to hand but from memory 
> I think there are probably around 800-1000 fields or so. I will confirm on 
> Monday.
>
> If i have time over the weekend I will try and recreate the problem at home 
> and see if I can post up a sample.
> 
> From: Yonik Seeley [ysee...@gmail.com]
> Sent: 19 February 2016 16:25
> To: solr-user@lucene.apache.org
> Subject: Re: Slow commits
>
> On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk> 
> wrote:
>> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
>> commits on one of my cores. The core in question is relatively small (56k 
>> docs) and the issue only shows when commiting after a number of deletes, 
>> commiting after additions is fine. As an example commiting after deleting 
>> approximately 10% of the documents takes around 25mins. The same test on the 
>> 4.10.2 instance takes around 1 second.
>>
>> I have done some investigation and the problem appears to be caused by 
>> having dynamic fields, the core in question has a large number, performing 
>> the same operation on this core with the dynamic fields removed sees a big 
>> improvement on the performance with the commit taking 11 seconds (still not 
>> quite on a par with 4.10.2).
>
> Dynamic fields is a Solr schema concept, and does not translate to any
> differences in Lucene.
> You may be hitting something due to a large number of fields (at the
> lucene level, each field name is a different field).  How many
> different fields (i.e. fieldnames) do you have across the entire
> index?
>
> -Yonik
>
> #
>
> This E-mail is the property of Mass Consultants Ltd. It is confidential and 
> intended only for the use of the addressee or with its permission.  Use by 
> anyone else for any purpose is prohibited.  If you are not the addressee, you 
> should not use, disclose, copy or distribute this e-mail and should notify us 
> of receipt immediately by return e-mail to the address where the e-mail 
> originated.
>
> This E-mail may not have been sent through a secure system and accordingly 
> (i) its contents should not be relied upon by any person without independent 
> verification from Mass Consultants Ltd and (ii) it is the responsibility of 
> the recipient to ensure that the onward transmission, opening or use of this 
> message and any attachments will not adversely affect its systems or data. No 
> responsibility is accepted by Mass Consultants Ltd in this regard.
>
> Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may be 
> monitored by systems or persons other than the addressee, for the purposes of 
> ascertaining whether the communication complies with the law and Mass 
> Consultants Ltd's policies.
>
> Mass Consultants Ltd is registered in England No. 1705804, Enterprise House, 
> Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom. Tel: +44 
> (0) 1480 222600.
>
> #
>
> #
>
> This E-mail is the property of Mass Consultants Ltd. It is confidential and 
> intended only for the use of the addressee or with its permission.  Use by 
> anyone else for any purpose is prohibited.  If you are not the addressee, you 
> should not use, disclose, copy or distribute this e-mail and should notify us 
> of receipt immediately by return e-mail to the address where the e-mail 
> originated.
>
> This E-mail may not have been sent through a secure system and accordingly 
> (i) its contents should not be relied upon by any person without independent 
> verification from Mass Consultants Ltd and (ii) it is the responsibility of 

RE: Slow commits

[Adam Neal [Extranet]]

Yup, that's correct. Not talking massive amounts of data really. The commit 
performance difference between 4.10.2 and 5.3.1 is huge in this case.

From: Susheel Kumar [susheel2...@gmail.com]
Sent: 22 February 2016 13:31
To: solr-user@lucene.apache.org
Subject: Re: Slow commits

Sorry, I see now you mentioned 56K docs which is pretty small.

On Mon, Feb 22, 2016 at 8:30 AM, Susheel Kumar <susheel2...@gmail.com>
wrote:

> Adam - how many documents you have in your index?
>
> Thanks,
> Susheel
>
> On Mon, Feb 22, 2016 at 4:37 AM, Adam Neal [Extranet] <an...@mass.co.uk>
> wrote:
>
>> Well I got the numbers wrong, there are actually around 66000 fields on
>> the index. I have restructured the index and there are now around 1500
>> fiields. This has resulted in the commit taking 34 seconds which is
>> acceptable for my usage however it is still significantly slower than the
>> 4.10.2 commit on the original 66000 fields which was around 1 second.
>> 
>> From: Adam Neal [Extranet] [an...@mass.co.uk]
>> Sent: 19 February 2016 17:43
>> To: solr-user@lucene.apache.org
>> Subject: RE: Slow commits
>>
>> I'm out of the office now so I don't have the numbers to hand but from
>> memory I think there are probably around 800-1000 fields or so. I will
>> confirm on Monday.
>>
>> If i have time over the weekend I will try and recreate the problem at
>> home and see if I can post up a sample.
>> ________
>> From: Yonik Seeley [ysee...@gmail.com]
>> Sent: 19 February 2016 16:25
>> To: solr-user@lucene.apache.org
>> Subject: Re: Slow commits
>>
>> On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk>
>> wrote:
>> > I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with
>> slow commits on one of my cores. The core in question is relatively small
>> (56k docs) and the issue only shows when commiting after a number of
>> deletes, commiting after additions is fine. As an example commiting after
>> deleting approximately 10% of the documents takes around 25mins. The same
>> test on the 4.10.2 instance takes around 1 second.
>> >
>> > I have done some investigation and the problem appears to be caused by
>> having dynamic fields, the core in question has a large number, performing
>> the same operation on this core with the dynamic fields removed sees a big
>> improvement on the performance with the commit taking 11 seconds (still not
>> quite on a par with 4.10.2).
>>
>> Dynamic fields is a Solr schema concept, and does not translate to any
>> differences in Lucene.
>> You may be hitting something due to a large number of fields (at the
>> lucene level, each field name is a different field).  How many
>> different fields (i.e. fieldnames) do you have across the entire
>> index?
>>
>> -Yonik
>>
>>
>> #
>>
>> This E-mail is the property of Mass Consultants Ltd. It is confidential
>> and intended only for the use of the addressee or with its permission.  Use
>> by anyone else for any purpose is prohibited.  If you are not the
>> addressee, you should not use, disclose, copy or distribute this e-mail and
>> should notify us of receipt immediately by return e-mail to the address
>> where the e-mail originated.
>>
>> This E-mail may not have been sent through a secure system and
>> accordingly (i) its contents should not be relied upon by any person
>> without independent verification from Mass Consultants Ltd and (ii) it is
>> the responsibility of the recipient to ensure that the onward transmission,
>> opening or use of this message and any attachments will not adversely
>> affect its systems or data. No responsibility is accepted by Mass
>> Consultants Ltd in this regard.
>>
>> Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may
>> be monitored by systems or persons other than the addressee, for the
>> purposes of ascertaining whether the communication complies with the law
>> and Mass Consultants Ltd's policies.
>>
>> Mass Consultants Ltd is registered in England No. 1705804, Enterprise
>> House, Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom.
>> Tel: +44 (0) 1480 222600.
>>
>>
>> #
>>
>>
>> #

Re: Slow commits

[Susheel Kumar]

Sorry, I see now you mentioned 56K docs which is pretty small.

On Mon, Feb 22, 2016 at 8:30 AM, Susheel Kumar <susheel2...@gmail.com>
wrote:

> Adam - how many documents you have in your index?
>
> Thanks,
> Susheel
>
> On Mon, Feb 22, 2016 at 4:37 AM, Adam Neal [Extranet] <an...@mass.co.uk>
> wrote:
>
>> Well I got the numbers wrong, there are actually around 66000 fields on
>> the index. I have restructured the index and there are now around 1500
>> fiields. This has resulted in the commit taking 34 seconds which is
>> acceptable for my usage however it is still significantly slower than the
>> 4.10.2 commit on the original 66000 fields which was around 1 second.
>> 
>> From: Adam Neal [Extranet] [an...@mass.co.uk]
>> Sent: 19 February 2016 17:43
>> To: solr-user@lucene.apache.org
>> Subject: RE: Slow commits
>>
>> I'm out of the office now so I don't have the numbers to hand but from
>> memory I think there are probably around 800-1000 fields or so. I will
>> confirm on Monday.
>>
>> If i have time over the weekend I will try and recreate the problem at
>> home and see if I can post up a sample.
>> ________
>> From: Yonik Seeley [ysee...@gmail.com]
>> Sent: 19 February 2016 16:25
>> To: solr-user@lucene.apache.org
>> Subject: Re: Slow commits
>>
>> On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk>
>> wrote:
>> > I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with
>> slow commits on one of my cores. The core in question is relatively small
>> (56k docs) and the issue only shows when commiting after a number of
>> deletes, commiting after additions is fine. As an example commiting after
>> deleting approximately 10% of the documents takes around 25mins. The same
>> test on the 4.10.2 instance takes around 1 second.
>> >
>> > I have done some investigation and the problem appears to be caused by
>> having dynamic fields, the core in question has a large number, performing
>> the same operation on this core with the dynamic fields removed sees a big
>> improvement on the performance with the commit taking 11 seconds (still not
>> quite on a par with 4.10.2).
>>
>> Dynamic fields is a Solr schema concept, and does not translate to any
>> differences in Lucene.
>> You may be hitting something due to a large number of fields (at the
>> lucene level, each field name is a different field).  How many
>> different fields (i.e. fieldnames) do you have across the entire
>> index?
>>
>> -Yonik
>>
>>
>> #
>>
>> This E-mail is the property of Mass Consultants Ltd. It is confidential
>> and intended only for the use of the addressee or with its permission.  Use
>> by anyone else for any purpose is prohibited.  If you are not the
>> addressee, you should not use, disclose, copy or distribute this e-mail and
>> should notify us of receipt immediately by return e-mail to the address
>> where the e-mail originated.
>>
>> This E-mail may not have been sent through a secure system and
>> accordingly (i) its contents should not be relied upon by any person
>> without independent verification from Mass Consultants Ltd and (ii) it is
>> the responsibility of the recipient to ensure that the onward transmission,
>> opening or use of this message and any attachments will not adversely
>> affect its systems or data. No responsibility is accepted by Mass
>> Consultants Ltd in this regard.
>>
>> Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may
>> be monitored by systems or persons other than the addressee, for the
>> purposes of ascertaining whether the communication complies with the law
>> and Mass Consultants Ltd's policies.
>>
>> Mass Consultants Ltd is registered in England No. 1705804, Enterprise
>> House, Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom.
>> Tel: +44 (0) 1480 222600.
>>
>>
>> #
>>
>>
>> #
>>
>> This E-mail is the property of Mass Consultants Ltd. It is confidential
>> and intended only for the use of the addressee or with its permission.  Use
>> by anyone else for any purpose is prohibited.  If you are not the
>> addressee, you should not use, disclose, copy 

Re: Slow commits

[Susheel Kumar]

Adam - how many documents you have in your index?

Thanks,
Susheel

On Mon, Feb 22, 2016 at 4:37 AM, Adam Neal [Extranet] <an...@mass.co.uk>
wrote:

> Well I got the numbers wrong, there are actually around 66000 fields on
> the index. I have restructured the index and there are now around 1500
> fiields. This has resulted in the commit taking 34 seconds which is
> acceptable for my usage however it is still significantly slower than the
> 4.10.2 commit on the original 66000 fields which was around 1 second.
> 
> From: Adam Neal [Extranet] [an...@mass.co.uk]
> Sent: 19 February 2016 17:43
> To: solr-user@lucene.apache.org
> Subject: RE: Slow commits
>
> I'm out of the office now so I don't have the numbers to hand but from
> memory I think there are probably around 800-1000 fields or so. I will
> confirm on Monday.
>
> If i have time over the weekend I will try and recreate the problem at
> home and see if I can post up a sample.
> 
> From: Yonik Seeley [ysee...@gmail.com]
> Sent: 19 February 2016 16:25
> To: solr-user@lucene.apache.org
> Subject: Re: Slow commits
>
> On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk>
> wrote:
> > I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with
> slow commits on one of my cores. The core in question is relatively small
> (56k docs) and the issue only shows when commiting after a number of
> deletes, commiting after additions is fine. As an example commiting after
> deleting approximately 10% of the documents takes around 25mins. The same
> test on the 4.10.2 instance takes around 1 second.
> >
> > I have done some investigation and the problem appears to be caused by
> having dynamic fields, the core in question has a large number, performing
> the same operation on this core with the dynamic fields removed sees a big
> improvement on the performance with the commit taking 11 seconds (still not
> quite on a par with 4.10.2).
>
> Dynamic fields is a Solr schema concept, and does not translate to any
> differences in Lucene.
> You may be hitting something due to a large number of fields (at the
> lucene level, each field name is a different field).  How many
> different fields (i.e. fieldnames) do you have across the entire
> index?
>
> -Yonik
>
>
> #
>
> This E-mail is the property of Mass Consultants Ltd. It is confidential
> and intended only for the use of the addressee or with its permission.  Use
> by anyone else for any purpose is prohibited.  If you are not the
> addressee, you should not use, disclose, copy or distribute this e-mail and
> should notify us of receipt immediately by return e-mail to the address
> where the e-mail originated.
>
> This E-mail may not have been sent through a secure system and accordingly
> (i) its contents should not be relied upon by any person without
> independent verification from Mass Consultants Ltd and (ii) it is the
> responsibility of the recipient to ensure that the onward transmission,
> opening or use of this message and any attachments will not adversely
> affect its systems or data. No responsibility is accepted by Mass
> Consultants Ltd in this regard.
>
> Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may
> be monitored by systems or persons other than the addressee, for the
> purposes of ascertaining whether the communication complies with the law
> and Mass Consultants Ltd's policies.
>
> Mass Consultants Ltd is registered in England No. 1705804, Enterprise
> House, Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom.
> Tel: +44 (0) 1480 222600.
>
>
> #
>
>
> #
>
> This E-mail is the property of Mass Consultants Ltd. It is confidential
> and intended only for the use of the addressee or with its permission.  Use
> by anyone else for any purpose is prohibited.  If you are not the
> addressee, you should not use, disclose, copy or distribute this e-mail and
> should notify us of receipt immediately by return e-mail to the address
> where the e-mail originated.
>
> This E-mail may not have been sent through a secure system and accordingly
> (i) its contents should not be relied upon by any person without
> independent verification from Mass Consultants Ltd and (ii) it is the
> responsibility of the recipient to ensure that the onward transmission,
> opening or use of this message and any attachments will not adversely
> 

RE: Slow commits

[Adam Neal [Extranet]]

Well I got the numbers wrong, there are actually around 66000 fields on the 
index. I have restructured the index and there are now around 1500 fiields. 
This has resulted in the commit taking 34 seconds which is acceptable for my 
usage however it is still significantly slower than the 4.10.2 commit on the 
original 66000 fields which was around 1 second.

From: Adam Neal [Extranet] [an...@mass.co.uk]
Sent: 19 February 2016 17:43
To: solr-user@lucene.apache.org
Subject: RE: Slow commits

I'm out of the office now so I don't have the numbers to hand but from memory I 
think there are probably around 800-1000 fields or so. I will confirm on Monday.

If i have time over the weekend I will try and recreate the problem at home and 
see if I can post up a sample.

From: Yonik Seeley [ysee...@gmail.com]
Sent: 19 February 2016 16:25
To: solr-user@lucene.apache.org
Subject: Re: Slow commits

On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk> wrote:
> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
> commits on one of my cores. The core in question is relatively small (56k 
> docs) and the issue only shows when commiting after a number of deletes, 
> commiting after additions is fine. As an example commiting after deleting 
> approximately 10% of the documents takes around 25mins. The same test on the 
> 4.10.2 instance takes around 1 second.
>
> I have done some investigation and the problem appears to be caused by having 
> dynamic fields, the core in question has a large number, performing the same 
> operation on this core with the dynamic fields removed sees a big improvement 
> on the performance with the commit taking 11 seconds (still not quite on a 
> par with 4.10.2).

Dynamic fields is a Solr schema concept, and does not translate to any
differences in Lucene.
You may be hitting something due to a large number of fields (at the
lucene level, each field name is a different field).  How many
different fields (i.e. fieldnames) do you have across the entire
index?

-Yonik

#

This E-mail is the property of Mass Consultants Ltd. It is confidential and 
intended only for the use of the addressee or with its permission.  Use by 
anyone else for any purpose is prohibited.  If you are not the addressee, you 
should not use, disclose, copy or distribute this e-mail and should notify us 
of receipt immediately by return e-mail to the address where the e-mail 
originated.

This E-mail may not have been sent through a secure system and accordingly (i) 
its contents should not be relied upon by any person without independent 
verification from Mass Consultants Ltd and (ii) it is the responsibility of the 
recipient to ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its systems or data. No 
responsibility is accepted by Mass Consultants Ltd in this regard.

Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may be 
monitored by systems or persons other than the addressee, for the purposes of 
ascertaining whether the communication complies with the law and Mass 
Consultants Ltd's policies.

Mass Consultants Ltd is registered in England No. 1705804, Enterprise House, 
Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom. Tel: +44 (0) 
1480 222600.

#

#

This E-mail is the property of Mass Consultants Ltd. It is confidential and 
intended only for the use of the addressee or with its permission.  Use by 
anyone else for any purpose is prohibited.  If you are not the addressee, you 
should not use, disclose, copy or distribute this e-mail and should notify us 
of receipt immediately by return e-mail to the address where the e-mail 
originated.

This E-mail may not have been sent through a secure system and accordingly (i) 
its contents should not be relied upon by any person without independent 
verification from Mass Consultants Ltd and (ii) it is the responsibility of the 
recipient to ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its systems or data. No 
responsibility is accepted by Mass Consultants Ltd in this regard.

Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may be 
monitored by systems or persons other than the addressee, for the purposes of 
ascertaining whether the communication complies with the law and Mass 
Consultants Ltd's policies.

Mass Consultants Ltd is registered in England No. 1705804, Enterprise House, 
Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom. Tel: +44 (0) 
1480 222600.

#

RE: Slow commits

[Adam Neal [Extranet]]

I'm out of the office now so I don't have the numbers to hand but from memory I 
think there are probably around 800-1000 fields or so. I will confirm on Monday.

If i have time over the weekend I will try and recreate the problem at home and 
see if I can post up a sample.

From: Yonik Seeley [ysee...@gmail.com]
Sent: 19 February 2016 16:25
To: solr-user@lucene.apache.org
Subject: Re: Slow commits

On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk> wrote:
> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
> commits on one of my cores. The core in question is relatively small (56k 
> docs) and the issue only shows when commiting after a number of deletes, 
> commiting after additions is fine. As an example commiting after deleting 
> approximately 10% of the documents takes around 25mins. The same test on the 
> 4.10.2 instance takes around 1 second.
>
> I have done some investigation and the problem appears to be caused by having 
> dynamic fields, the core in question has a large number, performing the same 
> operation on this core with the dynamic fields removed sees a big improvement 
> on the performance with the commit taking 11 seconds (still not quite on a 
> par with 4.10.2).

Dynamic fields is a Solr schema concept, and does not translate to any
differences in Lucene.
You may be hitting something due to a large number of fields (at the
lucene level, each field name is a different field).  How many
different fields (i.e. fieldnames) do you have across the entire
index?

-Yonik

#

This E-mail is the property of Mass Consultants Ltd. It is confidential and 
intended only for the use of the addressee or with its permission.  Use by 
anyone else for any purpose is prohibited.  If you are not the addressee, you 
should not use, disclose, copy or distribute this e-mail and should notify us 
of receipt immediately by return e-mail to the address where the e-mail 
originated.

This E-mail may not have been sent through a secure system and accordingly (i) 
its contents should not be relied upon by any person without independent 
verification from Mass Consultants Ltd and (ii) it is the responsibility of the 
recipient to ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its systems or data. No 
responsibility is accepted by Mass Consultants Ltd in this regard.

Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may be 
monitored by systems or persons other than the addressee, for the purposes of 
ascertaining whether the communication complies with the law and Mass 
Consultants Ltd's policies.

Mass Consultants Ltd is registered in England No. 1705804, Enterprise House, 
Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom. Tel: +44 (0) 
1480 222600.

#

Re: Slow commits

[Yonik Seeley]

On Fri, Feb 19, 2016 at 8:51 AM, Adam Neal [Extranet] <an...@mass.co.uk> wrote:
> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
> commits on one of my cores. The core in question is relatively small (56k 
> docs) and the issue only shows when commiting after a number of deletes, 
> commiting after additions is fine. As an example commiting after deleting 
> approximately 10% of the documents takes around 25mins. The same test on the 
> 4.10.2 instance takes around 1 second.
>
> I have done some investigation and the problem appears to be caused by having 
> dynamic fields, the core in question has a large number, performing the same 
> operation on this core with the dynamic fields removed sees a big improvement 
> on the performance with the commit taking 11 seconds (still not quite on a 
> par with 4.10.2).

Dynamic fields is a Solr schema concept, and does not translate to any
differences in Lucene.
You may be hitting something due to a large number of fields (at the
lucene level, each field name is a different field).  How many
different fields (i.e. fieldnames) do you have across the entire
index?

-Yonik

RE: Slow commits

[Adam Neal [Extranet]]

max heap on both instances is the same at 8gig, and only using around 1.5gig at 
the time of testing.

5.3.1 index size is 90MB 
4.10.2  index size is 125MB



From: Shawn Heisey [apa...@elyograg.org]
Sent: 19 February 2016 15:45
To: solr-user@lucene.apache.org
Subject: Re: Slow commits

On 2/19/2016 6:51 AM, Adam Neal [Extranet] wrote:
> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
> commits on one of my cores. The core in question is relatively small (56k 
> docs) and the issue only shows when commiting after a number of deletes, 
> commiting after additions is fine. As an example commiting after deleting 
> approximately 10% of the documents takes around 25mins. The same test on the 
> 4.10.2 instance takes around 1 second.

This sounds like one of two possibilities, with a strong possibility
that it's both:

* You are encountering extreme garbage collection pauses from a heap
that's too small.
* The deletes are leading to segment merges that are proceeding slowly.

What is the max heap set to on the new version?  Do you know what it was
set to on the old version?

How much disk space is used by your 56000 document index?

Thanks,
Shawn


#

This E-mail is the property of Mass Consultants Ltd. It is confidential and 
intended only for the use of the addressee or with its permission.  Use by 
anyone else for any purpose is prohibited.  If you are not the addressee, you 
should not use, disclose, copy or distribute this e-mail and should notify us 
of receipt immediately by return e-mail to the address where the e-mail 
originated.

This E-mail may not have been sent through a secure system and accordingly (i) 
its contents should not be relied upon by any person without independent 
verification from Mass Consultants Ltd and (ii) it is the responsibility of the 
recipient to ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its systems or data. No 
responsibility is accepted by Mass Consultants Ltd in this regard.

Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may be 
monitored by systems or persons other than the addressee, for the purposes of 
ascertaining whether the communication complies with the law and Mass 
Consultants Ltd's policies.

Mass Consultants Ltd is registered in England No. 1705804, Enterprise House, 
Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom. Tel: +44 (0) 
1480 222600.

#

Re: Slow commits

[Shawn Heisey]

On 2/19/2016 6:51 AM, Adam Neal [Extranet] wrote:
> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
> commits on one of my cores. The core in question is relatively small (56k 
> docs) and the issue only shows when commiting after a number of deletes, 
> commiting after additions is fine. As an example commiting after deleting 
> approximately 10% of the documents takes around 25mins. The same test on the 
> 4.10.2 instance takes around 1 second.

This sounds like one of two possibilities, with a strong possibility
that it's both:

* You are encountering extreme garbage collection pauses from a heap
that's too small.
* The deletes are leading to segment merges that are proceeding slowly.

What is the max heap set to on the new version?  Do you know what it was
set to on the old version?

How much disk space is used by your 56000 document index?

Thanks,
Shawn

RE: Slow commits

[Adam Neal [Extranet]]

Just some additional information, the problem is mainly when the dynamic fields 
are stored. Just having them indexed reduces the commit time to around 20 
seconds. Unfortunately I need them stored.

From: Adam Neal [Extranet] [an...@mass.co.uk]
Sent: 19 February 2016 13:51
To: solr-user@lucene.apache.org
Subject: Slow commits


I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
commits on one of my cores. The core in question is relatively small (56k docs) 
and the issue only shows when commiting after a number of deletes, commiting 
after additions is fine. As an example commiting after deleting approximately 
10% of the documents takes around 25mins. The same test on the 4.10.2 instance 
takes around 1 second.

I have done some investigation and the problem appears to be caused by having 
dynamic fields, the core in question has a large number, performing the same 
operation on this core with the dynamic fields removed sees a big improvement 
on the performance with the commit taking 11 seconds (still not quite on a par 
with 4.10.2).

At the moment for this core it is quicker in 5.3.1 to delete everything and 
reindex the data than it is to delete old documents.

Are there any changes that may have caused this or anything I should be doing 
differently in 5.3.1?

I intend to download 5.4.1 next week to see if that improves things.

Thanks

Adam


#

This E-mail is the property of Mass Consultants Ltd. It is confidential and 
intended only for the use of the addressee or with its permission.  Use by 
anyone else for any purpose is prohibited.  If you are not the addressee, you 
should not use, disclose, copy or distribute this e-mail and should notify us 
of receipt immediately by return e-mail to the address where the e-mail 
originated.

This E-mail may not have been sent through a secure system and accordingly (i) 
its contents should not be relied upon by any person without independent 
verification from Mass Consultants Ltd and (ii) it is the responsibility of the 
recipient to ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its systems or data. No 
responsibility is accepted by Mass Consultants Ltd in this regard.

Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may be 
monitored by systems or persons other than the addressee, for the purposes of 
ascertaining whether the communication complies with the law and Mass 
Consultants Ltd's policies.

Mass Consultants Ltd is registered in England No. 1705804, Enterprise House, 
Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom. Tel: +44 (0) 
1480 222600.

#

Slow commits

[Adam Neal [Extranet]]

I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue with slow 
commits on one of my cores. The core in question is relatively small (56k docs) 
and the issue only shows when commiting after a number of deletes, commiting 
after additions is fine. As an example commiting after deleting approximately 
10% of the documents takes around 25mins. The same test on the 4.10.2 instance 
takes around 1 second.

I have done some investigation and the problem appears to be caused by having 
dynamic fields, the core in question has a large number, performing the same 
operation on this core with the dynamic fields removed sees a big improvement 
on the performance with the commit taking 11 seconds (still not quite on a par 
with 4.10.2).

At the moment for this core it is quicker in 5.3.1 to delete everything and 
reindex the data than it is to delete old documents.

Are there any changes that may have caused this or anything I should be doing 
differently in 5.3.1?

I intend to download 5.4.1 next week to see if that improves things.

Thanks

Adam

#

This E-mail is the property of Mass Consultants Ltd. It is confidential and 
intended only for the use of the addressee or with its permission.  Use by 
anyone else for any purpose is prohibited.  If you are not the addressee, you 
should not use, disclose, copy or distribute this e-mail and should notify us 
of receipt immediately by return e-mail to the address where the e-mail 
originated.

This E-mail may not have been sent through a secure system and accordingly (i) 
its contents should not be relied upon by any person without independent 
verification from Mass Consultants Ltd and (ii) it is the responsibility of the 
recipient to ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its systems or data. No 
responsibility is accepted by Mass Consultants Ltd in this regard.

Any e-mails that are sent to Mass Consultants Ltd's e-mail addresses may be 
monitored by systems or persons other than the addressee, for the purposes of 
ascertaining whether the communication complies with the law and Mass 
Consultants Ltd's policies.

Mass Consultants Ltd is registered in England No. 1705804, Enterprise House, 
Great North Road, Little Paxton, Cambs., PE19 6BN, United Kingdom. Tel: +44 (0) 
1480 222600.

#

RE: very slow commits and overlapping commits

[Tirthankar Chatterjee]

Try looking at your warming queries. Create a warming query that will not 
return ay results. See if it helps returning commits faster. 

Thx

-Original Message-
From: Bill Au [mailto:bill.w...@gmail.com] 
Sent: Friday, May 27, 2011 3:47 PM
To: solr-user@lucene.apache.org
Subject: Re: very slow commits and overlapping commits

I managed to get a thread dump during a slow commit:

resin-tcp-connection-*:5062-129 Id=12721 in RUNNABLE total cpu 
time=391530.ms user time=390620.ms at java.lang.String.intern(Native 
Method) at
org.apache.lucene.util.SimpleStringInterner.intern(SimpleStringInterner.java:74)
at org.apache.lucene.util.StringHelper.intern(StringHelper.java:36)
at org.apache.lucene.index.FieldInfos.read(FieldInfos.java:356)
at org.apache.lucene.index.FieldInfos.(FieldInfos.java:71)
at
org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.java:116)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:638)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:608)
at org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:691)
at org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:667)
at
org.apache.lucene.index.DocumentsWriter.applyDeletes(DocumentsWriter.java:956)
at org.apache.lucene.index.IndexWriter.applyDeletes(IndexWriter.java:5207)
at
org.apache.lucene.index.IndexWriter.doFlushInternal(IndexWriter.java:4370)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:4209)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:4200)
at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:2195)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:2158)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:2122)
at org.apache.solr.update.SolrIndexWriter.close(SolrIndexWriter.java:230)
at
org.apache.solr.update.DirectUpdateHandler2.closeWriter(DirectUpdateHandler2.java:181)
at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:409)
at
org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:85)
at
org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:107)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:48)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at
com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:173)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520)
at com.caucho.util.ThreadPool.run(ThreadPool.java:442)
at java.lang.Thread.run(Thread.java:619)

It looks like Lucene's StringHelper is hardcoding the max size of the hash 
table of SimpleStringInterner to 1024 and I might be hitting that limit, 
causing an actual call to java.lang.String.intern().

I think I need to reduce the number of fields in my index.  Any other things I 
can do to help in this case.

Bill

On Wed, May 25, 2011 at 11:28 AM, Bill Au bill.w...@gmail.com wrote:

 I am taking a snapshot after every commit.  From looking at the 
 snapshots, it does not look like the delay in caused by segments 
 merging because I am not seeing any large new segments after a commit.

 I still can't figure out why there is a 2 minutes gap between start 
 commit and SolrDelectionPolicy.onCommit.  Will changing the 
 deletion policy make any difference?  I am using the default deletion policy 
 now.

 Bill

 2011/5/21 Erick Erickson erickerick...@gmail.com

 Well, committing less offside a possibilty  g. Here's what's 
 probably happening. When you pass certain thresholds, segments are 
 merged which can take quite some time.  His are you triggering 
 commits? If it's external, think about using auto commit instead.

 Best
 Erick
 On May 20, 2011 6:04 PM, Bill Au bill.w...@gmail.com wrote:
  On my Solr 1.4.1 master I am doing commits regularly at a fixed
 interval.
 I
  noticed that from time to time commit will take longer than the 
  commit interval, causing commits to overlap. Then things will get 
  worse as
 commit
  will take longer and longer. Here is the logs for a long commit:
 
 
  [2011-05-18 23:47:30.071] start
 

 commit(optimize=false,waitFlush=false,waitSearcher=false,expungeDelet
 es=false)
  [2011-05-18 23:49:48.119] SolrDeletionPolicy.onCommit: 
  commits:num=2
  [2011-05-18 23:49:48.119]
 

 commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpa,v

Re: very slow commits and overlapping commits

[Bill Au]

I managed to get a thread dump during a slow commit:

resin-tcp-connection-*:5062-129 Id=12721 in RUNNABLE total cpu
time=391530.ms user time=390620.ms
at java.lang.String.intern(Native Method)
at
org.apache.lucene.util.SimpleStringInterner.intern(SimpleStringInterner.java:74)
at org.apache.lucene.util.StringHelper.intern(StringHelper.java:36)
at org.apache.lucene.index.FieldInfos.read(FieldInfos.java:356)
at org.apache.lucene.index.FieldInfos.(FieldInfos.java:71)
at
org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.java:116)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:638)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:608)
at org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:691)
at org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:667)
at
org.apache.lucene.index.DocumentsWriter.applyDeletes(DocumentsWriter.java:956)
at org.apache.lucene.index.IndexWriter.applyDeletes(IndexWriter.java:5207)
at
org.apache.lucene.index.IndexWriter.doFlushInternal(IndexWriter.java:4370)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:4209)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:4200)
at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:2195)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:2158)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:2122)
at org.apache.solr.update.SolrIndexWriter.close(SolrIndexWriter.java:230)
at
org.apache.solr.update.DirectUpdateHandler2.closeWriter(DirectUpdateHandler2.java:181)
at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:409)
at
org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:85)
at
org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:107)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:48)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at
com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:173)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520)
at com.caucho.util.ThreadPool.run(ThreadPool.java:442)
at java.lang.Thread.run(Thread.java:619)

It looks like Lucene's StringHelper is hardcoding the max size of the hash
table of SimpleStringInterner to 1024 and I might be hitting that limit,
causing an actual call to java.lang.String.intern().

I think I need to reduce the number of fields in my index.  Any other things
I can do to help in this case.

Bill

On Wed, May 25, 2011 at 11:28 AM, Bill Au bill.w...@gmail.com wrote:

 I am taking a snapshot after every commit.  From looking at the snapshots,
 it does not look like the delay in caused by segments merging because I am
 not seeing any large new segments after a commit.

 I still can't figure out why there is a 2 minutes gap between start
 commit and SolrDelectionPolicy.onCommit.  Will changing the deletion
 policy make any difference?  I am using the default deletion policy now.

 Bill

 2011/5/21 Erick Erickson erickerick...@gmail.com

 Well, committing less offside a possibilty  g. Here's what's probably
 happening. When you pass certain thresholds, segments are merged which can
 take quite some time.  His are you triggering commits? If it's external,
 think about using auto commit instead.

 Best
 Erick
 On May 20, 2011 6:04 PM, Bill Au bill.w...@gmail.com wrote:
  On my Solr 1.4.1 master I am doing commits regularly at a fixed
 interval.
 I
  noticed that from time to time commit will take longer than the commit
  interval, causing commits to overlap. Then things will get worse as
 commit
  will take longer and longer. Here is the logs for a long commit:
 
 
  [2011-05-18 23:47:30.071] start
 

 commit(optimize=false,waitFlush=false,waitSearcher=false,expungeDeletes=false)
  [2011-05-18 23:49:48.119] SolrDeletionPolicy.onCommit: commits:num=2
  [2011-05-18 23:49:48.119]
 

 commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpa,version=1247782702272,generation=249742,filenames=[_4dqu_2g.del,
  _4e66.tis, _4e3r.tis, _4e59.nrm, _4e68_1.del, _4e4n.prx, _4e4n.fnm,
  _4e67.fnm, _4e3r.frq, _4e3r.tii, _4e6d.fnm, _4e6c.prx, _4e68.fdx,
 _4e68.nrm,
  _4e6a.frq, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt,
 _4e0e.nrm,
  _4e4n.tis, _4e6e.fnm, _4e3r.prx, _4e66.fnm, _4e3r.nrm, _4e0e.prx,
 

Re: very slow commits and overlapping commits

[Bill Au]

I am taking a snapshot after every commit.  From looking at the snapshots,
it does not look like the delay in caused by segments merging because I am
not seeing any large new segments after a commit.

I still can't figure out why there is a 2 minutes gap between start commit
and SolrDelectionPolicy.onCommit.  Will changing the deletion policy make
any difference?  I am using the default deletion policy now.

Bill

2011/5/21 Erick Erickson erickerick...@gmail.com

 Well, committing less offside a possibilty  g. Here's what's probably
 happening. When you pass certain thresholds, segments are merged which can
 take quite some time.  His are you triggering commits? If it's external,
 think about using auto commit instead.

 Best
 Erick
 On May 20, 2011 6:04 PM, Bill Au bill.w...@gmail.com wrote:
  On my Solr 1.4.1 master I am doing commits regularly at a fixed interval.
 I
  noticed that from time to time commit will take longer than the commit
  interval, causing commits to overlap. Then things will get worse as
 commit
  will take longer and longer. Here is the logs for a long commit:
 
 
  [2011-05-18 23:47:30.071] start
 

 commit(optimize=false,waitFlush=false,waitSearcher=false,expungeDeletes=false)
  [2011-05-18 23:49:48.119] SolrDeletionPolicy.onCommit: commits:num=2
  [2011-05-18 23:49:48.119]
 

 commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpa,version=1247782702272,generation=249742,filenames=[_4dqu_2g.del,
  _4e66.tis, _4e3r.tis, _4e59.nrm, _4e68_1.del, _4e4n.prx, _4e4n.fnm,
  _4e67.fnm, _4e3r.frq, _4e3r.tii, _4e6d.fnm, _4e6c.prx, _4e68.fdx,
 _4e68.nrm,
  _4e6a.frq, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt,
 _4e0e.nrm,
  _4e4n.tis, _4e6e.fnm, _4e3r.prx, _4e66.fnm, _4e3r.nrm, _4e0e.prx,
 _4e4c.fdx,
  _4dx1.prx, _4e5v.frq, _4e3r.fdt, _4e4c.tis, _4e41_6.del, _4e6b.tis,
  _4e6b_1.del, _4e4y_3.del, _4e6b.tii, _4e3r.fdx, _4dx1.nrm, _4e4y.frq,
  _4e4c.fdt, _4e4c.tii, _4e6d.fdt, _4e5k.fnm, _4e41.fnm, _4e69.fnm,
 _4e67.fdt,
  _4e0e.tii, _4dty_h.del, _4e6b.fnm, _4e0e_h.del, _4e6d.fdx, _4e67.fdx,
  _4e0e.tis, _4e5v.nrm, _4dx1.fnm, _4e5v.tii, _4dqu.fdt, segments_5cpa,
  _4e5v.prx, _4dqu.fdx, _4e59.fnm, _4e6d.prx, _4e59_5.del, _4e4c.prx,
  _4e4c.nrm, _4e5k.prx, _4e66.fdx, _4dty.frq, _4e6c.frq, _4e5v.tis,
 _4e6e.tii,
  _4e66.fdt, _4e6b.fdx, _4e68.prx, _4e59.fdx, _4e6e.fdt, _4e41.prx,
 _4dx1.tii,
  _4dx1.fdt, _4e6b.fdt, _4e5v_4.del, _4e4n.fdt, _4e6e.fdx, _4dx1.fdx,
  _4e41.nrm, _4e4n.fdx, _4e6e.tis, _4e66.tii, _4e4c.fnm, _4e6b.prx,
 _4e67.prx,
  _4e0e.fnm, _4e4n.nrm, _4e67.nrm, _4e5k.nrm, _4e6a.prx, _4e68.fnm,
  _4e4c_4.del, _4dx1.tis, _4e6e.nrm, _4e59.tii, _4e68.tis, _4e67.frq,
  _4e3r.fnm, _4dty.nrm, _4e4y.prx, _4e6e.prx, _4dty.tis, _4e4y.tis,
 _4e6b.nrm,
  _4e6a.fdt, _4e4n.frq, _4e6d.frq, _4e59.fdt, _4e6a.fdx, _4e6a.fnm,
 _4dqu.tii,
  _4e41.tii, _4e67_1.del, _4e41.tis, _4dty.fdt, _4e69.tis, _4dqu.frq,
  _4dty.fdx, _4dx1.frq, _4e6e.frq, _4e66_1.del, _4e69.prx, _4e6d.tii,
  _4e5k.tii, _4e0e.fdt, _4dqu.tis, _4e6d.tis, _4e69.nrm, _4dqu.prx,
 _4e4y.fnm,
  _4e67.tis, _4e69_1.del, _4e6d.nrm, _4e6c.tis, _4e0e.fdx, _4e6c.tii,
  _4dx1_n.del, _4e5v.fnm, _4e5k.tis, _4e59.tis, _4e67.tii, _4dqu.nrm,
  _4e5k_8.del, _4e6c.fdx, _4e6c.fdt, _4e41.frq, _4e4y.fdx, _4e69.frq,
  _4e6a.tis, _4dty.prx, _4e66.frq, _4e5k.frq, _4e6a.tii, _4e69.tii,
 _4e6c.nrm,
  _4dty.fnm, _4e59.prx, _4e59.frq, _4e66.prx, _4e68.frq, _4e5k.fdx,
 _4e4y.tii,
  _4e6c.fnm, _4e0e.frq, _4e6b.frq, _4e41.fdt, _4e4n_2.del, _4dty.tii,
  _4e4y.fdt, _4e66.nrm, _4e4c.frq, _4e6a.nrm, _4e5k.fdt, _4e3r_i.del,
  _4e5v.fdt, _4e4y.nrm, _4e68.tii, _4e5v.fdx, _4e41.fdx]
  [2011-05-18 23:49:48.119]
 

 commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpb,version=1247782702273,generation=249743,filenames=[_4dqu_2g.del,
  _4e66.tis, _4e59.nrm, _4e3r.tis, _4e4n.fnm, _4e67.fnm, _4e3r.tii,
 _4e6d.fnm,
  _4e68.fdx, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt,
 _4e4n.tis,
  _4e6e.fnm, _4e0e.prx, _4e4c.tis, _4e5v.frq, _4e4y_3.del, _4e6b_1.del,
  _4e4c.tii, _4e6f.fnm, _4e5k.fnm, _4e6c_1.del, _4e41.fnm, _4dx1.fnm,
  _4e5v.nrm, _4e5v.tii, _4e5v.prx, _4e5k.prx, _4e4c.nrm, _4dty.frq,
 _4e66.fdx,
  _4e5v.tis, _4e66.fdt, _4e6e.tii, _4e59.fdx, _4e6b.fdx, _4e41.prx,
 _4e6b.fdt,
  _4e41.nrm, _4e6e.tis, _4e4c.fnm, _4e66.tii, _4e6b.prx, _4e0e.fnm,
 _4e5k.nrm,
  _4e6a.prx, _4e6e.nrm, _4e59.tii, _4e67.frq, _4dty.nrm, _4e4y.tis,
 _4e6a.fdt,
  _4e6b.nrm, _4e59.fdt, _4e6a.fdx, _4e41.tii, _4e41.tis, _4e67_1.del,
  _4dty.fdt, _4dty.fdx, _4e69.tis, _4e66_1.del, _4e6e.frq, _4e5k.tii,
  _4dqu.prx, _4e67.tis, _4e69_1.del, _4e6c.tis, _4e6c.tii, _4e5v.fnm,
  _4e5k.tis, _4e59.tis, _4e67.tii, _4e6c.fdx, _4e4y.fdx, _4e41.frq,
 _4e6c.fdt,
  _4dty.prx, _4e66.frq, _4e69.tii, _4e6c.nrm, _4e59.frq, _4e66.prx,
 _4e5k.fdx,
  _4e68.frq, _4e4y.tii, _4e4n_2.del, _4e41.fdt, _4e6b.frq, _4e4y.fdt,
  _4e66.nrm, _4e4c.frq, _4e3r_i.del, _4e5k.fdt, _4e4y.nrm, _4e41.fdx,
  _4e4n.prx, _4e68_1.del, _4e3r.frq, _4e6f.fdt, _4e6f.fdx, _4e6c.prx,
  _4e68.nrm, _4e6a.frq, 

Re: very slow commits and overlapping commits

[Bill Au]

You can use the postCommit event listener as an callback mechanism to let
you know that a commit has happened.

Bill

On Sun, May 22, 2011 at 9:31 PM, Jeff Crump jeffrey.cr...@gmail.com wrote:

 I don't have an answer to this but only another question:  I don't think I
 can use auto-commit in my application, as I have to checkpoint my index
 submissions and I don't know of any callback mechanism that would let me
 know a commit has happened.  Is there one?

 2011/5/21 Erick Erickson erickerick...@gmail.com

  Well, committing less offside a possibilty  g. Here's what's probably
  happening. When you pass certain thresholds, segments are merged which
 can
  take quite some time.  His are you triggering commits? If it's external,
  think about using auto commit instead.
 
  Best
  Erick
  On May 20, 2011 6:04 PM, Bill Au bill.w...@gmail.com wrote:
   On my Solr 1.4.1 master I am doing commits regularly at a fixed
 interval.
  I
   noticed that from time to time commit will take longer than the commit
   interval, causing commits to overlap. Then things will get worse as
  commit
   will take longer and longer. Here is the logs for a long commit:
  
  
   [2011-05-18 23:47:30.071] start
  
 
 
 commit(optimize=false,waitFlush=false,waitSearcher=false,expungeDeletes=false)
   [2011-05-18 23:49:48.119] SolrDeletionPolicy.onCommit: commits:num=2
   [2011-05-18 23:49:48.119]
  
 
 
 commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpa,version=1247782702272,generation=249742,filenames=[_4dqu_2g.del,
   _4e66.tis, _4e3r.tis, _4e59.nrm, _4e68_1.del, _4e4n.prx, _4e4n.fnm,
   _4e67.fnm, _4e3r.frq, _4e3r.tii, _4e6d.fnm, _4e6c.prx, _4e68.fdx,
  _4e68.nrm,
   _4e6a.frq, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt,
  _4e0e.nrm,
   _4e4n.tis, _4e6e.fnm, _4e3r.prx, _4e66.fnm, _4e3r.nrm, _4e0e.prx,
  _4e4c.fdx,
   _4dx1.prx, _4e5v.frq, _4e3r.fdt, _4e4c.tis, _4e41_6.del, _4e6b.tis,
   _4e6b_1.del, _4e4y_3.del, _4e6b.tii, _4e3r.fdx, _4dx1.nrm, _4e4y.frq,
   _4e4c.fdt, _4e4c.tii, _4e6d.fdt, _4e5k.fnm, _4e41.fnm, _4e69.fnm,
  _4e67.fdt,
   _4e0e.tii, _4dty_h.del, _4e6b.fnm, _4e0e_h.del, _4e6d.fdx, _4e67.fdx,
   _4e0e.tis, _4e5v.nrm, _4dx1.fnm, _4e5v.tii, _4dqu.fdt, segments_5cpa,
   _4e5v.prx, _4dqu.fdx, _4e59.fnm, _4e6d.prx, _4e59_5.del, _4e4c.prx,
   _4e4c.nrm, _4e5k.prx, _4e66.fdx, _4dty.frq, _4e6c.frq, _4e5v.tis,
  _4e6e.tii,
   _4e66.fdt, _4e6b.fdx, _4e68.prx, _4e59.fdx, _4e6e.fdt, _4e41.prx,
  _4dx1.tii,
   _4dx1.fdt, _4e6b.fdt, _4e5v_4.del, _4e4n.fdt, _4e6e.fdx, _4dx1.fdx,
   _4e41.nrm, _4e4n.fdx, _4e6e.tis, _4e66.tii, _4e4c.fnm, _4e6b.prx,
  _4e67.prx,
   _4e0e.fnm, _4e4n.nrm, _4e67.nrm, _4e5k.nrm, _4e6a.prx, _4e68.fnm,
   _4e4c_4.del, _4dx1.tis, _4e6e.nrm, _4e59.tii, _4e68.tis, _4e67.frq,
   _4e3r.fnm, _4dty.nrm, _4e4y.prx, _4e6e.prx, _4dty.tis, _4e4y.tis,
  _4e6b.nrm,
   _4e6a.fdt, _4e4n.frq, _4e6d.frq, _4e59.fdt, _4e6a.fdx, _4e6a.fnm,
  _4dqu.tii,
   _4e41.tii, _4e67_1.del, _4e41.tis, _4dty.fdt, _4e69.tis, _4dqu.frq,
   _4dty.fdx, _4dx1.frq, _4e6e.frq, _4e66_1.del, _4e69.prx, _4e6d.tii,
   _4e5k.tii, _4e0e.fdt, _4dqu.tis, _4e6d.tis, _4e69.nrm, _4dqu.prx,
  _4e4y.fnm,
   _4e67.tis, _4e69_1.del, _4e6d.nrm, _4e6c.tis, _4e0e.fdx, _4e6c.tii,
   _4dx1_n.del, _4e5v.fnm, _4e5k.tis, _4e59.tis, _4e67.tii, _4dqu.nrm,
   _4e5k_8.del, _4e6c.fdx, _4e6c.fdt, _4e41.frq, _4e4y.fdx, _4e69.frq,
   _4e6a.tis, _4dty.prx, _4e66.frq, _4e5k.frq, _4e6a.tii, _4e69.tii,
  _4e6c.nrm,
   _4dty.fnm, _4e59.prx, _4e59.frq, _4e66.prx, _4e68.frq, _4e5k.fdx,
  _4e4y.tii,
   _4e6c.fnm, _4e0e.frq, _4e6b.frq, _4e41.fdt, _4e4n_2.del, _4dty.tii,
   _4e4y.fdt, _4e66.nrm, _4e4c.frq, _4e6a.nrm, _4e5k.fdt, _4e3r_i.del,
   _4e5v.fdt, _4e4y.nrm, _4e68.tii, _4e5v.fdx, _4e41.fdx]
   [2011-05-18 23:49:48.119]
  
 
 
 commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpb,version=1247782702273,generation=249743,filenames=[_4dqu_2g.del,
   _4e66.tis, _4e59.nrm, _4e3r.tis, _4e4n.fnm, _4e67.fnm, _4e3r.tii,
  _4e6d.fnm,
   _4e68.fdx, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt,
  _4e4n.tis,
   _4e6e.fnm, _4e0e.prx, _4e4c.tis, _4e5v.frq, _4e4y_3.del, _4e6b_1.del,
   _4e4c.tii, _4e6f.fnm, _4e5k.fnm, _4e6c_1.del, _4e41.fnm, _4dx1.fnm,
   _4e5v.nrm, _4e5v.tii, _4e5v.prx, _4e5k.prx, _4e4c.nrm, _4dty.frq,
  _4e66.fdx,
   _4e5v.tis, _4e66.fdt, _4e6e.tii, _4e59.fdx, _4e6b.fdx, _4e41.prx,
  _4e6b.fdt,
   _4e41.nrm, _4e6e.tis, _4e4c.fnm, _4e66.tii, _4e6b.prx, _4e0e.fnm,
  _4e5k.nrm,
   _4e6a.prx, _4e6e.nrm, _4e59.tii, _4e67.frq, _4dty.nrm, _4e4y.tis,
  _4e6a.fdt,
   _4e6b.nrm, _4e59.fdt, _4e6a.fdx, _4e41.tii, _4e41.tis, _4e67_1.del,
   _4dty.fdt, _4dty.fdx, _4e69.tis, _4e66_1.del, _4e6e.frq, _4e5k.tii,
   _4dqu.prx, _4e67.tis, _4e69_1.del, _4e6c.tis, _4e6c.tii, _4e5v.fnm,
   _4e5k.tis, _4e59.tis, _4e67.tii, _4e6c.fdx, _4e4y.fdx, _4e41.frq,
  _4e6c.fdt,
   _4dty.prx, _4e66.frq, _4e69.tii, _4e6c.nrm, _4e59.frq, _4e66.prx,
  _4e5k.fdx,
   _4e68.frq, _4e4y.tii, _4e4n_2.del, _4e41.fdt, _4e6b.frq, _4e4y.fdt,
   _4e66.nrm, _4e4c.frq, 

Re: very slow commits and overlapping commits

[Jeff Crump]

I don't have an answer to this but only another question:  I don't think I
can use auto-commit in my application, as I have to checkpoint my index
submissions and I don't know of any callback mechanism that would let me
know a commit has happened.  Is there one?

2011/5/21 Erick Erickson erickerick...@gmail.com

 Well, committing less offside a possibilty  g. Here's what's probably
 happening. When you pass certain thresholds, segments are merged which can
 take quite some time.  His are you triggering commits? If it's external,
 think about using auto commit instead.

 Best
 Erick
 On May 20, 2011 6:04 PM, Bill Au bill.w...@gmail.com wrote:
  On my Solr 1.4.1 master I am doing commits regularly at a fixed interval.
 I
  noticed that from time to time commit will take longer than the commit
  interval, causing commits to overlap. Then things will get worse as
 commit
  will take longer and longer. Here is the logs for a long commit:
 
 
  [2011-05-18 23:47:30.071] start
 

 commit(optimize=false,waitFlush=false,waitSearcher=false,expungeDeletes=false)
  [2011-05-18 23:49:48.119] SolrDeletionPolicy.onCommit: commits:num=2
  [2011-05-18 23:49:48.119]
 

 commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpa,version=1247782702272,generation=249742,filenames=[_4dqu_2g.del,
  _4e66.tis, _4e3r.tis, _4e59.nrm, _4e68_1.del, _4e4n.prx, _4e4n.fnm,
  _4e67.fnm, _4e3r.frq, _4e3r.tii, _4e6d.fnm, _4e6c.prx, _4e68.fdx,
 _4e68.nrm,
  _4e6a.frq, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt,
 _4e0e.nrm,
  _4e4n.tis, _4e6e.fnm, _4e3r.prx, _4e66.fnm, _4e3r.nrm, _4e0e.prx,
 _4e4c.fdx,
  _4dx1.prx, _4e5v.frq, _4e3r.fdt, _4e4c.tis, _4e41_6.del, _4e6b.tis,
  _4e6b_1.del, _4e4y_3.del, _4e6b.tii, _4e3r.fdx, _4dx1.nrm, _4e4y.frq,
  _4e4c.fdt, _4e4c.tii, _4e6d.fdt, _4e5k.fnm, _4e41.fnm, _4e69.fnm,
 _4e67.fdt,
  _4e0e.tii, _4dty_h.del, _4e6b.fnm, _4e0e_h.del, _4e6d.fdx, _4e67.fdx,
  _4e0e.tis, _4e5v.nrm, _4dx1.fnm, _4e5v.tii, _4dqu.fdt, segments_5cpa,
  _4e5v.prx, _4dqu.fdx, _4e59.fnm, _4e6d.prx, _4e59_5.del, _4e4c.prx,
  _4e4c.nrm, _4e5k.prx, _4e66.fdx, _4dty.frq, _4e6c.frq, _4e5v.tis,
 _4e6e.tii,
  _4e66.fdt, _4e6b.fdx, _4e68.prx, _4e59.fdx, _4e6e.fdt, _4e41.prx,
 _4dx1.tii,
  _4dx1.fdt, _4e6b.fdt, _4e5v_4.del, _4e4n.fdt, _4e6e.fdx, _4dx1.fdx,
  _4e41.nrm, _4e4n.fdx, _4e6e.tis, _4e66.tii, _4e4c.fnm, _4e6b.prx,
 _4e67.prx,
  _4e0e.fnm, _4e4n.nrm, _4e67.nrm, _4e5k.nrm, _4e6a.prx, _4e68.fnm,
  _4e4c_4.del, _4dx1.tis, _4e6e.nrm, _4e59.tii, _4e68.tis, _4e67.frq,
  _4e3r.fnm, _4dty.nrm, _4e4y.prx, _4e6e.prx, _4dty.tis, _4e4y.tis,
 _4e6b.nrm,
  _4e6a.fdt, _4e4n.frq, _4e6d.frq, _4e59.fdt, _4e6a.fdx, _4e6a.fnm,
 _4dqu.tii,
  _4e41.tii, _4e67_1.del, _4e41.tis, _4dty.fdt, _4e69.tis, _4dqu.frq,
  _4dty.fdx, _4dx1.frq, _4e6e.frq, _4e66_1.del, _4e69.prx, _4e6d.tii,
  _4e5k.tii, _4e0e.fdt, _4dqu.tis, _4e6d.tis, _4e69.nrm, _4dqu.prx,
 _4e4y.fnm,
  _4e67.tis, _4e69_1.del, _4e6d.nrm, _4e6c.tis, _4e0e.fdx, _4e6c.tii,
  _4dx1_n.del, _4e5v.fnm, _4e5k.tis, _4e59.tis, _4e67.tii, _4dqu.nrm,
  _4e5k_8.del, _4e6c.fdx, _4e6c.fdt, _4e41.frq, _4e4y.fdx, _4e69.frq,
  _4e6a.tis, _4dty.prx, _4e66.frq, _4e5k.frq, _4e6a.tii, _4e69.tii,
 _4e6c.nrm,
  _4dty.fnm, _4e59.prx, _4e59.frq, _4e66.prx, _4e68.frq, _4e5k.fdx,
 _4e4y.tii,
  _4e6c.fnm, _4e0e.frq, _4e6b.frq, _4e41.fdt, _4e4n_2.del, _4dty.tii,
  _4e4y.fdt, _4e66.nrm, _4e4c.frq, _4e6a.nrm, _4e5k.fdt, _4e3r_i.del,
  _4e5v.fdt, _4e4y.nrm, _4e68.tii, _4e5v.fdx, _4e41.fdx]
  [2011-05-18 23:49:48.119]
 

 commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpb,version=1247782702273,generation=249743,filenames=[_4dqu_2g.del,
  _4e66.tis, _4e59.nrm, _4e3r.tis, _4e4n.fnm, _4e67.fnm, _4e3r.tii,
 _4e6d.fnm,
  _4e68.fdx, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt,
 _4e4n.tis,
  _4e6e.fnm, _4e0e.prx, _4e4c.tis, _4e5v.frq, _4e4y_3.del, _4e6b_1.del,
  _4e4c.tii, _4e6f.fnm, _4e5k.fnm, _4e6c_1.del, _4e41.fnm, _4dx1.fnm,
  _4e5v.nrm, _4e5v.tii, _4e5v.prx, _4e5k.prx, _4e4c.nrm, _4dty.frq,
 _4e66.fdx,
  _4e5v.tis, _4e66.fdt, _4e6e.tii, _4e59.fdx, _4e6b.fdx, _4e41.prx,
 _4e6b.fdt,
  _4e41.nrm, _4e6e.tis, _4e4c.fnm, _4e66.tii, _4e6b.prx, _4e0e.fnm,
 _4e5k.nrm,
  _4e6a.prx, _4e6e.nrm, _4e59.tii, _4e67.frq, _4dty.nrm, _4e4y.tis,
 _4e6a.fdt,
  _4e6b.nrm, _4e59.fdt, _4e6a.fdx, _4e41.tii, _4e41.tis, _4e67_1.del,
  _4dty.fdt, _4dty.fdx, _4e69.tis, _4e66_1.del, _4e6e.frq, _4e5k.tii,
  _4dqu.prx, _4e67.tis, _4e69_1.del, _4e6c.tis, _4e6c.tii, _4e5v.fnm,
  _4e5k.tis, _4e59.tis, _4e67.tii, _4e6c.fdx, _4e4y.fdx, _4e41.frq,
 _4e6c.fdt,
  _4dty.prx, _4e66.frq, _4e69.tii, _4e6c.nrm, _4e59.frq, _4e66.prx,
 _4e5k.fdx,
  _4e68.frq, _4e4y.tii, _4e4n_2.del, _4e41.fdt, _4e6b.frq, _4e4y.fdt,
  _4e66.nrm, _4e4c.frq, _4e3r_i.del, _4e5k.fdt, _4e4y.nrm, _4e41.fdx,
  _4e4n.prx, _4e68_1.del, _4e3r.frq, _4e6f.fdt, _4e6f.fdx, _4e6c.prx,
  _4e68.nrm, _4e6a.frq, _4e0e.nrm, _4e3r.prx, _4e66.fnm, _4e3r.nrm,
 _4e4c.fdx,
  _4dx1.prx, _4e3r.fdt, _4e41_6.del, _4e6b.tis, _4e3r.fdx, _4e6b.tii,
  _4dx1.nrm, _4e4y.frq, _4e4c.fdt, 

Re: very slow commits and overlapping commits

[Erick Erickson]

Well, committing less offside a possibilty  g. Here's what's probably
happening. When you pass certain thresholds, segments are merged which can
take quite some time.  His are you triggering commits? If it's external,
think about using auto commit instead.

Best
Erick
On May 20, 2011 6:04 PM, Bill Au bill.w...@gmail.com wrote:
 On my Solr 1.4.1 master I am doing commits regularly at a fixed interval.
I
 noticed that from time to time commit will take longer than the commit
 interval, causing commits to overlap. Then things will get worse as commit
 will take longer and longer. Here is the logs for a long commit:


 [2011-05-18 23:47:30.071] start

commit(optimize=false,waitFlush=false,waitSearcher=false,expungeDeletes=false)
 [2011-05-18 23:49:48.119] SolrDeletionPolicy.onCommit: commits:num=2
 [2011-05-18 23:49:48.119]

commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpa,version=1247782702272,generation=249742,filenames=[_4dqu_2g.del,
 _4e66.tis, _4e3r.tis, _4e59.nrm, _4e68_1.del, _4e4n.prx, _4e4n.fnm,
 _4e67.fnm, _4e3r.frq, _4e3r.tii, _4e6d.fnm, _4e6c.prx, _4e68.fdx,
_4e68.nrm,
 _4e6a.frq, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt,
_4e0e.nrm,
 _4e4n.tis, _4e6e.fnm, _4e3r.prx, _4e66.fnm, _4e3r.nrm, _4e0e.prx,
_4e4c.fdx,
 _4dx1.prx, _4e5v.frq, _4e3r.fdt, _4e4c.tis, _4e41_6.del, _4e6b.tis,
 _4e6b_1.del, _4e4y_3.del, _4e6b.tii, _4e3r.fdx, _4dx1.nrm, _4e4y.frq,
 _4e4c.fdt, _4e4c.tii, _4e6d.fdt, _4e5k.fnm, _4e41.fnm, _4e69.fnm,
_4e67.fdt,
 _4e0e.tii, _4dty_h.del, _4e6b.fnm, _4e0e_h.del, _4e6d.fdx, _4e67.fdx,
 _4e0e.tis, _4e5v.nrm, _4dx1.fnm, _4e5v.tii, _4dqu.fdt, segments_5cpa,
 _4e5v.prx, _4dqu.fdx, _4e59.fnm, _4e6d.prx, _4e59_5.del, _4e4c.prx,
 _4e4c.nrm, _4e5k.prx, _4e66.fdx, _4dty.frq, _4e6c.frq, _4e5v.tis,
_4e6e.tii,
 _4e66.fdt, _4e6b.fdx, _4e68.prx, _4e59.fdx, _4e6e.fdt, _4e41.prx,
_4dx1.tii,
 _4dx1.fdt, _4e6b.fdt, _4e5v_4.del, _4e4n.fdt, _4e6e.fdx, _4dx1.fdx,
 _4e41.nrm, _4e4n.fdx, _4e6e.tis, _4e66.tii, _4e4c.fnm, _4e6b.prx,
_4e67.prx,
 _4e0e.fnm, _4e4n.nrm, _4e67.nrm, _4e5k.nrm, _4e6a.prx, _4e68.fnm,
 _4e4c_4.del, _4dx1.tis, _4e6e.nrm, _4e59.tii, _4e68.tis, _4e67.frq,
 _4e3r.fnm, _4dty.nrm, _4e4y.prx, _4e6e.prx, _4dty.tis, _4e4y.tis,
_4e6b.nrm,
 _4e6a.fdt, _4e4n.frq, _4e6d.frq, _4e59.fdt, _4e6a.fdx, _4e6a.fnm,
_4dqu.tii,
 _4e41.tii, _4e67_1.del, _4e41.tis, _4dty.fdt, _4e69.tis, _4dqu.frq,
 _4dty.fdx, _4dx1.frq, _4e6e.frq, _4e66_1.del, _4e69.prx, _4e6d.tii,
 _4e5k.tii, _4e0e.fdt, _4dqu.tis, _4e6d.tis, _4e69.nrm, _4dqu.prx,
_4e4y.fnm,
 _4e67.tis, _4e69_1.del, _4e6d.nrm, _4e6c.tis, _4e0e.fdx, _4e6c.tii,
 _4dx1_n.del, _4e5v.fnm, _4e5k.tis, _4e59.tis, _4e67.tii, _4dqu.nrm,
 _4e5k_8.del, _4e6c.fdx, _4e6c.fdt, _4e41.frq, _4e4y.fdx, _4e69.frq,
 _4e6a.tis, _4dty.prx, _4e66.frq, _4e5k.frq, _4e6a.tii, _4e69.tii,
_4e6c.nrm,
 _4dty.fnm, _4e59.prx, _4e59.frq, _4e66.prx, _4e68.frq, _4e5k.fdx,
_4e4y.tii,
 _4e6c.fnm, _4e0e.frq, _4e6b.frq, _4e41.fdt, _4e4n_2.del, _4dty.tii,
 _4e4y.fdt, _4e66.nrm, _4e4c.frq, _4e6a.nrm, _4e5k.fdt, _4e3r_i.del,
 _4e5v.fdt, _4e4y.nrm, _4e68.tii, _4e5v.fdx, _4e41.fdx]
 [2011-05-18 23:49:48.119]

commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpb,version=1247782702273,generation=249743,filenames=[_4dqu_2g.del,
 _4e66.tis, _4e59.nrm, _4e3r.tis, _4e4n.fnm, _4e67.fnm, _4e3r.tii,
_4e6d.fnm,
 _4e68.fdx, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt,
_4e4n.tis,
 _4e6e.fnm, _4e0e.prx, _4e4c.tis, _4e5v.frq, _4e4y_3.del, _4e6b_1.del,
 _4e4c.tii, _4e6f.fnm, _4e5k.fnm, _4e6c_1.del, _4e41.fnm, _4dx1.fnm,
 _4e5v.nrm, _4e5v.tii, _4e5v.prx, _4e5k.prx, _4e4c.nrm, _4dty.frq,
_4e66.fdx,
 _4e5v.tis, _4e66.fdt, _4e6e.tii, _4e59.fdx, _4e6b.fdx, _4e41.prx,
_4e6b.fdt,
 _4e41.nrm, _4e6e.tis, _4e4c.fnm, _4e66.tii, _4e6b.prx, _4e0e.fnm,
_4e5k.nrm,
 _4e6a.prx, _4e6e.nrm, _4e59.tii, _4e67.frq, _4dty.nrm, _4e4y.tis,
_4e6a.fdt,
 _4e6b.nrm, _4e59.fdt, _4e6a.fdx, _4e41.tii, _4e41.tis, _4e67_1.del,
 _4dty.fdt, _4dty.fdx, _4e69.tis, _4e66_1.del, _4e6e.frq, _4e5k.tii,
 _4dqu.prx, _4e67.tis, _4e69_1.del, _4e6c.tis, _4e6c.tii, _4e5v.fnm,
 _4e5k.tis, _4e59.tis, _4e67.tii, _4e6c.fdx, _4e4y.fdx, _4e41.frq,
_4e6c.fdt,
 _4dty.prx, _4e66.frq, _4e69.tii, _4e6c.nrm, _4e59.frq, _4e66.prx,
_4e5k.fdx,
 _4e68.frq, _4e4y.tii, _4e4n_2.del, _4e41.fdt, _4e6b.frq, _4e4y.fdt,
 _4e66.nrm, _4e4c.frq, _4e3r_i.del, _4e5k.fdt, _4e4y.nrm, _4e41.fdx,
 _4e4n.prx, _4e68_1.del, _4e3r.frq, _4e6f.fdt, _4e6f.fdx, _4e6c.prx,
 _4e68.nrm, _4e6a.frq, _4e0e.nrm, _4e3r.prx, _4e66.fnm, _4e3r.nrm,
_4e4c.fdx,
 _4dx1.prx, _4e3r.fdt, _4e41_6.del, _4e6b.tis, _4e3r.fdx, _4e6b.tii,
 _4dx1.nrm, _4e4y.frq, _4e4c.fdt, _4e6d.fdt, _4e69.fnm, _4dty_h.del,
 _4e0e.tii, _4e67.fdt, _4e0e_h.del, _4e6b.fnm, _4e6d.fdx, _4e67.fdx,
 _4e0e.tis, _4dqu.fdt, segments_5cpb, _4dqu.fdx, _4e59.fnm, _4e59_5.del,
 _4e6d.prx, _4e4c.prx, _4e6c.frq, _4e68.prx, _4e6e.fdt, _4dx1.tii,
_4dx1.fdt,
 _4e4n.fdt, _4e5v_4.del, _4e6e.fdx, _4dx1.fdx, _4e4n.fdx, _4e6f.nrm,
 _4e4n.nrm, _4e67.prx, _4e67.nrm, _4e68.fnm, _4e4c_4.del, _4dx1.tis,
 _4e68.tis, 

very slow commits and overlapping commits

[Bill Au]

On my Solr 1.4.1 master I am doing commits regularly at a fixed interval.  I
noticed that from time to time commit will take longer than the commit
interval, causing commits to overlap.  Then things will get worse as commit
will take longer and longer.  Here is the logs for a long commit:


[2011-05-18 23:47:30.071] start
commit(optimize=false,waitFlush=false,waitSearcher=false,expungeDeletes=false)
[2011-05-18 23:49:48.119] SolrDeletionPolicy.onCommit: commits:num=2
[2011-05-18 23:49:48.119]
commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpa,version=1247782702272,generation=249742,filenames=[_4dqu_2g.del,
_4e66.tis, _4e3r.tis, _4e59.nrm, _4e68_1.del, _4e4n.prx, _4e4n.fnm,
_4e67.fnm, _4e3r.frq, _4e3r.tii, _4e6d.fnm, _4e6c.prx, _4e68.fdx, _4e68.nrm,
_4e6a.frq, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt, _4e0e.nrm,
_4e4n.tis, _4e6e.fnm, _4e3r.prx, _4e66.fnm, _4e3r.nrm, _4e0e.prx, _4e4c.fdx,
_4dx1.prx, _4e5v.frq, _4e3r.fdt, _4e4c.tis, _4e41_6.del, _4e6b.tis,
_4e6b_1.del, _4e4y_3.del, _4e6b.tii, _4e3r.fdx, _4dx1.nrm, _4e4y.frq,
_4e4c.fdt, _4e4c.tii, _4e6d.fdt, _4e5k.fnm, _4e41.fnm, _4e69.fnm, _4e67.fdt,
_4e0e.tii, _4dty_h.del, _4e6b.fnm, _4e0e_h.del, _4e6d.fdx, _4e67.fdx,
_4e0e.tis, _4e5v.nrm, _4dx1.fnm, _4e5v.tii, _4dqu.fdt, segments_5cpa,
_4e5v.prx, _4dqu.fdx, _4e59.fnm, _4e6d.prx, _4e59_5.del, _4e4c.prx,
_4e4c.nrm, _4e5k.prx, _4e66.fdx, _4dty.frq, _4e6c.frq, _4e5v.tis, _4e6e.tii,
_4e66.fdt, _4e6b.fdx, _4e68.prx, _4e59.fdx, _4e6e.fdt, _4e41.prx, _4dx1.tii,
_4dx1.fdt, _4e6b.fdt, _4e5v_4.del, _4e4n.fdt, _4e6e.fdx, _4dx1.fdx,
_4e41.nrm, _4e4n.fdx, _4e6e.tis, _4e66.tii, _4e4c.fnm, _4e6b.prx, _4e67.prx,
_4e0e.fnm, _4e4n.nrm, _4e67.nrm, _4e5k.nrm, _4e6a.prx, _4e68.fnm,
_4e4c_4.del, _4dx1.tis, _4e6e.nrm, _4e59.tii, _4e68.tis, _4e67.frq,
_4e3r.fnm, _4dty.nrm, _4e4y.prx, _4e6e.prx, _4dty.tis, _4e4y.tis, _4e6b.nrm,
_4e6a.fdt, _4e4n.frq, _4e6d.frq, _4e59.fdt, _4e6a.fdx, _4e6a.fnm, _4dqu.tii,
_4e41.tii, _4e67_1.del, _4e41.tis, _4dty.fdt, _4e69.tis, _4dqu.frq,
_4dty.fdx, _4dx1.frq, _4e6e.frq, _4e66_1.del, _4e69.prx, _4e6d.tii,
_4e5k.tii, _4e0e.fdt, _4dqu.tis, _4e6d.tis, _4e69.nrm, _4dqu.prx, _4e4y.fnm,
_4e67.tis, _4e69_1.del, _4e6d.nrm, _4e6c.tis, _4e0e.fdx, _4e6c.tii,
_4dx1_n.del, _4e5v.fnm, _4e5k.tis, _4e59.tis, _4e67.tii, _4dqu.nrm,
_4e5k_8.del, _4e6c.fdx, _4e6c.fdt, _4e41.frq, _4e4y.fdx, _4e69.frq,
_4e6a.tis, _4dty.prx, _4e66.frq, _4e5k.frq, _4e6a.tii, _4e69.tii, _4e6c.nrm,
_4dty.fnm, _4e59.prx, _4e59.frq, _4e66.prx, _4e68.frq, _4e5k.fdx, _4e4y.tii,
_4e6c.fnm, _4e0e.frq, _4e6b.frq, _4e41.fdt, _4e4n_2.del, _4dty.tii,
_4e4y.fdt, _4e66.nrm, _4e4c.frq, _4e6a.nrm, _4e5k.fdt, _4e3r_i.del,
_4e5v.fdt, _4e4y.nrm, _4e68.tii, _4e5v.fdx, _4e41.fdx]
[2011-05-18 23:49:48.119]
commit{dir=/var/opt/resin3/5062/solr/data/index,segFN=segments_5cpb,version=1247782702273,generation=249743,filenames=[_4dqu_2g.del,
_4e66.tis, _4e59.nrm, _4e3r.tis, _4e4n.fnm, _4e67.fnm, _4e3r.tii, _4e6d.fnm,
_4e68.fdx, _4e68.fdt, _4dqu.fnm, _4e4n.tii, _4e69.fdx, _4e69.fdt, _4e4n.tis,
_4e6e.fnm, _4e0e.prx, _4e4c.tis, _4e5v.frq, _4e4y_3.del, _4e6b_1.del,
_4e4c.tii, _4e6f.fnm, _4e5k.fnm, _4e6c_1.del, _4e41.fnm, _4dx1.fnm,
_4e5v.nrm, _4e5v.tii, _4e5v.prx, _4e5k.prx, _4e4c.nrm, _4dty.frq, _4e66.fdx,
_4e5v.tis, _4e66.fdt, _4e6e.tii, _4e59.fdx, _4e6b.fdx, _4e41.prx, _4e6b.fdt,
_4e41.nrm, _4e6e.tis, _4e4c.fnm, _4e66.tii, _4e6b.prx, _4e0e.fnm, _4e5k.nrm,
_4e6a.prx, _4e6e.nrm, _4e59.tii, _4e67.frq, _4dty.nrm, _4e4y.tis, _4e6a.fdt,
_4e6b.nrm, _4e59.fdt, _4e6a.fdx, _4e41.tii, _4e41.tis, _4e67_1.del,
_4dty.fdt, _4dty.fdx, _4e69.tis, _4e66_1.del, _4e6e.frq, _4e5k.tii,
_4dqu.prx, _4e67.tis, _4e69_1.del, _4e6c.tis, _4e6c.tii, _4e5v.fnm,
_4e5k.tis, _4e59.tis, _4e67.tii, _4e6c.fdx, _4e4y.fdx, _4e41.frq, _4e6c.fdt,
_4dty.prx, _4e66.frq, _4e69.tii, _4e6c.nrm, _4e59.frq, _4e66.prx, _4e5k.fdx,
_4e68.frq, _4e4y.tii, _4e4n_2.del, _4e41.fdt, _4e6b.frq, _4e4y.fdt,
_4e66.nrm, _4e4c.frq, _4e3r_i.del, _4e5k.fdt, _4e4y.nrm, _4e41.fdx,
_4e4n.prx, _4e68_1.del, _4e3r.frq, _4e6f.fdt, _4e6f.fdx, _4e6c.prx,
_4e68.nrm, _4e6a.frq, _4e0e.nrm, _4e3r.prx, _4e66.fnm, _4e3r.nrm, _4e4c.fdx,
_4dx1.prx, _4e3r.fdt, _4e41_6.del, _4e6b.tis, _4e3r.fdx, _4e6b.tii,
_4dx1.nrm, _4e4y.frq, _4e4c.fdt, _4e6d.fdt, _4e69.fnm, _4dty_h.del,
_4e0e.tii, _4e67.fdt, _4e0e_h.del, _4e6b.fnm, _4e6d.fdx, _4e67.fdx,
_4e0e.tis, _4dqu.fdt, segments_5cpb, _4dqu.fdx, _4e59.fnm, _4e59_5.del,
_4e6d.prx, _4e4c.prx, _4e6c.frq, _4e68.prx, _4e6e.fdt, _4dx1.tii, _4dx1.fdt,
_4e4n.fdt, _4e5v_4.del, _4e6e.fdx, _4dx1.fdx, _4e4n.fdx, _4e6f.nrm,
_4e4n.nrm, _4e67.prx, _4e67.nrm, _4e68.fnm, _4e4c_4.del, _4dx1.tis,
_4e68.tis, _4e3r.fnm, _4e6f.prx, _4e4y.prx, _4dty.tis, _4e6e.prx, _4e4n.frq,
_4e6d.frq, _4dqu.tii, _4e6a.fnm, _4dx1.frq, _4dqu.frq, _4e69.prx, _4e6d.tii,
_4e0e.fdt, _4dqu.tis, _4e69.nrm, _4e6d.tis, _4e4y.fnm, _4e0e.fdx, _4e6d.nrm,
_4dx1_n.del, _4dqu.nrm, _4e6f.tii, _4e5k_8.del, _4e6f.frq, _4e69.frq,
_4e6a.tis, _4e6f.tis, _4e5k.frq, _4e6a.tii, _4dty.fnm, _4e59.prx, _4e6c.fnm,
_4e0e.frq, _4dty.tii, 

Re: Slow Commits

[Jim Murphy]

 for searc...@5df12234 main

 documentCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumu
 lative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.QuerySenderListener
 newSearcher
 INFO: QuerySenderListener sending requests to searc...@5df12234 main
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.QuerySenderListener
 newSearcher
 INFO: QuerySenderListener done.
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrCore registerSearcher
 INFO: [] Registered new searcher searc...@5df12234 main
 Oct 28, 2009 11:50:45 AM org.apache.solr.search.SolrIndexSearcher close
 INFO: Closing searc...@50e40833 main

 fieldValueCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cu
 mulative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}

 filterCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumula
 tive_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}

 queryResultCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,c
 umulative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}

 documentCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumu
 lative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrDeletionPolicy onInit
 INFO: SolrDeletionPolicy.onInit: commits:num=1

 commit{dir=/master/data/index,segFN=segments_8us5,version=1228872482132,generation=413141,filenames=[_ala9.fnm,
 _alaa_5.del, _alab
 .fnm, _962y_xgh.del, _al8x.frq, _akh1.tis, _add1.frq, _alae.tis,
 _7zfh_1gse.del, _alad.nrm, _alae.tii, _akuu.tis, _ah91_35m.del,
 _ailk.frq
 , _7zfh.tii, _962y.tis, _akuu.tii, _ah91.prx, _7zfh.tis, _ala8.frq,
 _962y.tii, _ala7.fnm, _akzu.fnm, _9wzn.fnm, _ala9_2.del, _ala8.nrm, _a
 laf.fnm, _alae.nrm, _ala9.prx, _ailk_24k.del, _alaf.prx, _al9w.prx,
 _ala8.prx, _akh1.tii, _akzu.tii, _akzu.tis, _alad.fnm, _al2o.fnm, _962
 y.fnm, _al8x_18.del, _ala7_7.del, _alaa.tis, _ala9.nrm, _ala9.tis,
 _alaa.tii, _962y.nrm, _ala9.tii, _a61p.prx, _add1_62v.del, _al8x.fnm, _
 7zfh.fnm, _al7i_2g.del, _ailk.fnm, _al8x.tii, _al8x.tis, _ala8.fnm,
 _akzu.frq, _9wzn.frq, _7zfh.nrm, _akuu.fdt, _alad.tii, _akuu.fdx, _aku
 u_cd.del, _a61p_b77.del, _alad.tis, _al2o_67.del, _add1.fdx, _9wzn.prx,
 _al9w.fdt, _add1.fdt, _al9w.fdx, _akuu.prx, _962y.frq, _9wzn.fdt,
 _alab_4.del, _9wzn.fdx, segments_8us5, _alac_4.del, _alae.fnm,
 _ailk.tis,
 _ala9.fdx, _alac.fnm, _ala9.fdt, _alab.prx, _alae_2.del, _alaa.f
 nm, _alad_1.del, _al9w.frq, _ailk.tii, _add1.tis, _alac.tii, _add1.tii,
 _alac.tis, _ala7.frq, _ah91.fnm, _a61p.fdt, _alae.prx, _akuu.frq,
 _a61p.fdx, _akh1_ng.del, _al7i.fdx, _al2o.tis, _al9w.tis, _a61p.frq,
 _akh1.prx, _9wzn_i0n.del, _al7i.fdt, _al7i.prx, _962y.prx, _al9w.tii,
  _al7i.frq, _ah91.tii, _962y.fdt, _akh1.fnm, _962y.fdx, _ah91.tis,
 _al8x.prx, _al2o.tii, _ala7.fdx, _ala7.fdt, _alaf.fdx, _alaf.fdt, _al2o
 .fdx, _7zfh.frq, _akzu.fdt, _alaf.nrm, _akzu.fdx, _alab.nrm, _al2o.fdt,
 _alaa.prx, _alaa.nrm, _ala7.prx, _ailk.fdt, _akzu.prx, _alac.frq,
 _ailk.prx, _alaf.tii, _alaf_1.del, _alae.frq, _add1.fnm, _alaf.tis,
 _7zfh.prx, _al9w.fnm, _ala9.frq, _alab.frq, _ala8.fdx, _akzu_8e.del, _
 ala8.fdt, _ailk.fdx, _alaa.frq, _al7i.tis, _7zfh.fdx, _al9w_i.del,
 _ah91.fdt, _al7i.tii, _ah91.fdx, _alad.fdx, _akuu.fnm, _add1.prx, _alae
 .fdx, _ah91.frq, _7zfh.fdt, _alad.fdt, _alae.fdt, _a61p.fnm, _alaf.frq,
 _ala8.tii, _a61p.tis, _9wzn.tii, _alad.frq, _ala8.tis, _alab.tii,
 _akh1.frq, _alab.tis, _al7i.fnm, _alab.fdx, _alac.nrm, _ala8_5.del,
 _ala7.tii, _alab.fdt, _alaa.fdx, _al2o.frq, _akh1.fdx, _alac.prx, _ala
 a.fdt, _al2o.prx, _akh1.fdt, _alad.prx, _ala7.tis, _alac.fdt, _a61p.tii,
 _9wzn.tis, _al8x.fdt, _alac.fdx, _al8x.fdx]
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrDeletionPolicy
 updateCommits
 INFO: last commit = 1228872482132
 Oct 28, 2009 11:50:45 AM
 org.apache.solr.update.processor.LogUpdateProcessor
 finish
 INFO: {add=[8e0d826fd83005f535bc930dac9fe65f]} 0 222916
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrCore execute
 INFO: [] webapp=/solrmaster path=/update params={} status=0 QTime=222916
 Oct 28,
 --
 View this message in context:
 http://www.nabble.com/Slow-Commits-tp26097538p26097538.html
 Sent from the Solr - User mailing list archive at Nabble.com.


 
 
 
 -- 
 Jerome Eteve.
 http://www.eteve.net
 jer...@eteve.net
 
 
 
 

-- 
View this message in context: 
http://old.nabble.com/Slow-Commits-tp26097538p26284779.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Slow Commits

[Jérôme Etévé]

,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumula
 tive_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}

 queryResultCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,c
 umulative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}

 documentCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumu
 lative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrDeletionPolicy onInit
 INFO: SolrDeletionPolicy.onInit: commits:num=1

 commit{dir=/master/data/index,segFN=segments_8us5,version=1228872482132,generation=413141,filenames=[_ala9.fnm,
 _alaa_5.del, _alab
 .fnm, _962y_xgh.del, _al8x.frq, _akh1.tis, _add1.frq, _alae.tis,
 _7zfh_1gse.del, _alad.nrm, _alae.tii, _akuu.tis, _ah91_35m.del, _ailk.frq
 , _7zfh.tii, _962y.tis, _akuu.tii, _ah91.prx, _7zfh.tis, _ala8.frq,
 _962y.tii, _ala7.fnm, _akzu.fnm, _9wzn.fnm, _ala9_2.del, _ala8.nrm, _a
 laf.fnm, _alae.nrm, _ala9.prx, _ailk_24k.del, _alaf.prx, _al9w.prx,
 _ala8.prx, _akh1.tii, _akzu.tii, _akzu.tis, _alad.fnm, _al2o.fnm, _962
 y.fnm, _al8x_18.del, _ala7_7.del, _alaa.tis, _ala9.nrm, _ala9.tis,
 _alaa.tii, _962y.nrm, _ala9.tii, _a61p.prx, _add1_62v.del, _al8x.fnm, _
 7zfh.fnm, _al7i_2g.del, _ailk.fnm, _al8x.tii, _al8x.tis, _ala8.fnm,
 _akzu.frq, _9wzn.frq, _7zfh.nrm, _akuu.fdt, _alad.tii, _akuu.fdx, _aku
 u_cd.del, _a61p_b77.del, _alad.tis, _al2o_67.del, _add1.fdx, _9wzn.prx,
 _al9w.fdt, _add1.fdt, _al9w.fdx, _akuu.prx, _962y.frq, _9wzn.fdt,
 _alab_4.del, _9wzn.fdx, segments_8us5, _alac_4.del, _alae.fnm, _ailk.tis,
 _ala9.fdx, _alac.fnm, _ala9.fdt, _alab.prx, _alae_2.del, _alaa.f
 nm, _alad_1.del, _al9w.frq, _ailk.tii, _add1.tis, _alac.tii, _add1.tii,
 _alac.tis, _ala7.frq, _ah91.fnm, _a61p.fdt, _alae.prx, _akuu.frq,
 _a61p.fdx, _akh1_ng.del, _al7i.fdx, _al2o.tis, _al9w.tis, _a61p.frq,
 _akh1.prx, _9wzn_i0n.del, _al7i.fdt, _al7i.prx, _962y.prx, _al9w.tii,
  _al7i.frq, _ah91.tii, _962y.fdt, _akh1.fnm, _962y.fdx, _ah91.tis,
 _al8x.prx, _al2o.tii, _ala7.fdx, _ala7.fdt, _alaf.fdx, _alaf.fdt, _al2o
 .fdx, _7zfh.frq, _akzu.fdt, _alaf.nrm, _akzu.fdx, _alab.nrm, _al2o.fdt,
 _alaa.prx, _alaa.nrm, _ala7.prx, _ailk.fdt, _akzu.prx, _alac.frq,
 _ailk.prx, _alaf.tii, _alaf_1.del, _alae.frq, _add1.fnm, _alaf.tis,
 _7zfh.prx, _al9w.fnm, _ala9.frq, _alab.frq, _ala8.fdx, _akzu_8e.del, _
 ala8.fdt, _ailk.fdx, _alaa.frq, _al7i.tis, _7zfh.fdx, _al9w_i.del,
 _ah91.fdt, _al7i.tii, _ah91.fdx, _alad.fdx, _akuu.fnm, _add1.prx, _alae
 .fdx, _ah91.frq, _7zfh.fdt, _alad.fdt, _alae.fdt, _a61p.fnm, _alaf.frq,
 _ala8.tii, _a61p.tis, _9wzn.tii, _alad.frq, _ala8.tis, _alab.tii,
 _akh1.frq, _alab.tis, _al7i.fnm, _alab.fdx, _alac.nrm, _ala8_5.del,
 _ala7.tii, _alab.fdt, _alaa.fdx, _al2o.frq, _akh1.fdx, _alac.prx, _ala
 a.fdt, _al2o.prx, _akh1.fdt, _alad.prx, _ala7.tis, _alac.fdt, _a61p.tii,
 _9wzn.tis, _al8x.fdt, _alac.fdx, _al8x.fdx]
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrDeletionPolicy
 updateCommits
 INFO: last commit = 1228872482132
 Oct 28, 2009 11:50:45 AM org.apache.solr.update.processor.LogUpdateProcessor
 finish
 INFO: {add=[8e0d826fd83005f535bc930dac9fe65f]} 0 222916
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrCore execute
 INFO: [] webapp=/solrmaster path=/update params={} status=0 QTime=222916
 Oct 28,
 --
 View this message in context: 
 http://www.nabble.com/Slow-Commits-tp26097538p26097538.html
 Sent from the Solr - User mailing list archive at Nabble.com.





-- 
Jerome Eteve.
http://www.eteve.net
jer...@eteve.net

Re: Slow Commits

[Jim Murphy]

 INFO: QuerySenderListener done.
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrCore registerSearcher
 INFO: [] Registered new searcher searc...@5df12234 main
 Oct 28, 2009 11:50:45 AM org.apache.solr.search.SolrIndexSearcher close
 INFO: Closing searc...@50e40833 main

 fieldValueCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cu
 mulative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}

 filterCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumula
 tive_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}

 queryResultCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,c
 umulative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}

 documentCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumu
 lative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrDeletionPolicy onInit
 INFO: SolrDeletionPolicy.onInit: commits:num=1

 commit{dir=/master/data/index,segFN=segments_8us5,version=1228872482132,generation=413141,filenames=[_ala9.fnm,
 _alaa_5.del, _alab
 .fnm, _962y_xgh.del, _al8x.frq, _akh1.tis, _add1.frq, _alae.tis,
 _7zfh_1gse.del, _alad.nrm, _alae.tii, _akuu.tis, _ah91_35m.del, _ailk.frq
 , _7zfh.tii, _962y.tis, _akuu.tii, _ah91.prx, _7zfh.tis, _ala8.frq,
 _962y.tii, _ala7.fnm, _akzu.fnm, _9wzn.fnm, _ala9_2.del, _ala8.nrm, _a
 laf.fnm, _alae.nrm, _ala9.prx, _ailk_24k.del, _alaf.prx, _al9w.prx,
 _ala8.prx, _akh1.tii, _akzu.tii, _akzu.tis, _alad.fnm, _al2o.fnm, _962
 y.fnm, _al8x_18.del, _ala7_7.del, _alaa.tis, _ala9.nrm, _ala9.tis,
 _alaa.tii, _962y.nrm, _ala9.tii, _a61p.prx, _add1_62v.del, _al8x.fnm, _
 7zfh.fnm, _al7i_2g.del, _ailk.fnm, _al8x.tii, _al8x.tis, _ala8.fnm,
 _akzu.frq, _9wzn.frq, _7zfh.nrm, _akuu.fdt, _alad.tii, _akuu.fdx, _aku
 u_cd.del, _a61p_b77.del, _alad.tis, _al2o_67.del, _add1.fdx, _9wzn.prx,
 _al9w.fdt, _add1.fdt, _al9w.fdx, _akuu.prx, _962y.frq, _9wzn.fdt,
 _alab_4.del, _9wzn.fdx, segments_8us5, _alac_4.del, _alae.fnm, _ailk.tis,
 _ala9.fdx, _alac.fnm, _ala9.fdt, _alab.prx, _alae_2.del, _alaa.f
 nm, _alad_1.del, _al9w.frq, _ailk.tii, _add1.tis, _alac.tii, _add1.tii,
 _alac.tis, _ala7.frq, _ah91.fnm, _a61p.fdt, _alae.prx, _akuu.frq,
 _a61p.fdx, _akh1_ng.del, _al7i.fdx, _al2o.tis, _al9w.tis, _a61p.frq,
 _akh1.prx, _9wzn_i0n.del, _al7i.fdt, _al7i.prx, _962y.prx, _al9w.tii,
  _al7i.frq, _ah91.tii, _962y.fdt, _akh1.fnm, _962y.fdx, _ah91.tis,
 _al8x.prx, _al2o.tii, _ala7.fdx, _ala7.fdt, _alaf.fdx, _alaf.fdt, _al2o
 .fdx, _7zfh.frq, _akzu.fdt, _alaf.nrm, _akzu.fdx, _alab.nrm, _al2o.fdt,
 _alaa.prx, _alaa.nrm, _ala7.prx, _ailk.fdt, _akzu.prx, _alac.frq,
 _ailk.prx, _alaf.tii, _alaf_1.del, _alae.frq, _add1.fnm, _alaf.tis,
 _7zfh.prx, _al9w.fnm, _ala9.frq, _alab.frq, _ala8.fdx, _akzu_8e.del, _
 ala8.fdt, _ailk.fdx, _alaa.frq, _al7i.tis, _7zfh.fdx, _al9w_i.del,
 _ah91.fdt, _al7i.tii, _ah91.fdx, _alad.fdx, _akuu.fnm, _add1.prx, _alae
 .fdx, _ah91.frq, _7zfh.fdt, _alad.fdt, _alae.fdt, _a61p.fnm, _alaf.frq,
 _ala8.tii, _a61p.tis, _9wzn.tii, _alad.frq, _ala8.tis, _alab.tii,
 _akh1.frq, _alab.tis, _al7i.fnm, _alab.fdx, _alac.nrm, _ala8_5.del,
 _ala7.tii, _alab.fdt, _alaa.fdx, _al2o.frq, _akh1.fdx, _alac.prx, _ala
 a.fdt, _al2o.prx, _akh1.fdt, _alad.prx, _ala7.tis, _alac.fdt, _a61p.tii,
 _9wzn.tis, _al8x.fdt, _alac.fdx, _al8x.fdx]
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrDeletionPolicy
 updateCommits
 INFO: last commit = 1228872482132
 Oct 28, 2009 11:50:45 AM
 org.apache.solr.update.processor.LogUpdateProcessor
 finish
 INFO: {add=[8e0d826fd83005f535bc930dac9fe65f]} 0 222916
 Oct 28, 2009 11:50:45 AM org.apache.solr.core.SolrCore execute
 INFO: [] webapp=/solrmaster path=/update params={} status=0 QTime=222916
 Oct 28,
 --
 View this message in context:
 http://www.nabble.com/Slow-Commits-tp26097538p26097538.html
 Sent from the Solr - User mailing list archive at Nabble.com.


 
 
 
 -- 
 Jerome Eteve.
 http://www.eteve.net
 jer...@eteve.net
 
 

-- 
View this message in context: 
http://www.nabble.com/Slow-Commits-tp26097538p26097871.html
Sent from the Solr - User mailing list archive at Nabble.com.

Selecting data with an order on string field causes slow commits from then on

[David Stevenson]

We have a table that has roughly 1M rows.

If we run a query against the table and order by a string field that has a
large number of unique values then subsequent commits of any other document
takes much longer.

If we don't run the query or if we order on a string field with very few
unique values (or don't order at all) the commits are unaffected.

Our question is, why does running a query and ordering on a string field
with a large number unique values affect all subsequent commits???

The only way we've found to fix the problem, once it has started, is to
restart solr.


Our test begins by executing a SOLR add like so:

add
  doc
field name=type_tUser/field
field name=pk_i13/field
field name=idUser:13/field
...
  /doc
/add
commit/ 
== This takes approx 0.3 sec

Then we do a SOLR select:
wt=rubyq=%28solr_categories_s%3Arestaurant%29%20AND%20type_t%3ARatable%3Bsolr_title_s%20ascstart=0fl=pk_i%2Cscoreqt=standard
== This takes approx 2 sec

Then we execute the SAME SOLR add command above and commit/ 
== This takes approx 3 sec

CONFIG INFO:
512mb heap, JVM 1.5, lucene-core-2007-05-20_00-04-53.jar, solr 1.2


-Chris  David