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] wrote:
> Highest count is fairly equal between string
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
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
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 thin
e.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
wrote:
> Adam - how many documents you have in your index?
>
> Thanks,
> Susheel
>
> On Mon, Feb 22, 2016 at 4:37 AM, Adam Neal [Extranet]
&
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:
ass.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 Mo
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 numbe
p 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] wrote:
> I've recently upgraded from 4.10.2 to 5.3.1 and I've hit an issue
On Fri, Feb 19, 2016 at 8: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,
> com
@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 commi
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
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
Just an update to the list. It appears that memory was the culprit. I
attached a JMX console to the running Tomcat instance and monitored memory
usage. Used Total memory stayed ~900MB till a commit then jumped to m Xmx
setting of 1.2GB where the "peak" flatlined and fell down likely after an
OO
Thanks Jerome,
1. I have shut off autowarming by setting params to 0.
2. My JVM Settings: -Xmx1200m -Xms1200m -XX:-UseGCOverheadLimit
-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=50
3. I am using autocommits - every 6 ms. But the commit blocks all the
master request threadpool
Hi, here's two thing that can slow down commits:
1) Autowarming the caches.
2) The Java old generation object garbage collection.
You can try:
- Turning autowarming off (set autowarmCount="0" in the caches configuration)
- If you use the sun jvm, use -XX:+UseConcMarkSweepGC to get a less
blocki
16 matches
Mail list logo
