I initially thought this was the case as well. These are slave nodes
that receive updates every 5-10 minutes. However, this issue happens
even if replication is turned off and no update handler is provided at all.
I have confirmed against my data that simply querying the fq for a
start_time in a r
Patrick,
Are you getting these stalls following a commit? If so then the issue is
most likely fieldCache warming pauses. To stop your users from seeing this
pause you'll need to add static warming queries to your solrconfig.xml to
warm the fieldCache before it's registered .
On Mon, Dec 9, 2013
Well, I want to include everything will start in the next 5 minute
interval and everything that came before. The query is more like:
fq=start_time:[* TO NOW+5MINUTE/5MINUTE]
so that it rounds to the nearest 5 minute interval on the right-hand
side. But, as soon as 1 second after that 5 minute win
Yeah, I tried G1, but it did not help - I don't think it is a garbage
collection issue. I've made various changes to iCMS as well and the
issue ALWAYS happens - no matter what I do. If I'm taking heavy traffic
(200 requests per second) - as soon as I hit a 5 minute mark - the world
stops - garbage
Did you add the Garbage collection JVM options I suggested you?
-XX:+UseG1GC -XX:MaxGCPauseMillis=50
Guido.
On 09/12/13 16:33, Patrick O'Lone wrote:
Unfortunately, in a test environment, this happens in version 4.4.0 of
Solr as well.
I was trying to locate the release notes for 3.6.x it is t
If you want a start time within the next 5 minutes, I think your filter
is not the good one.
* will be replaced by the first date in your field
Try :
fq=start_time:[NOW TO NOW+5MINUTE]
Franck Brisbart
Le lundi 09 décembre 2013 à 09:07 -0600, Patrick O'Lone a écrit :
> I have a new question abou
Unfortunately, in a test environment, this happens in version 4.4.0 of
Solr as well.
> I was trying to locate the release notes for 3.6.x it is too old, if I
> were you I would update to 3.6.2 (from 3.6.1), it shouldn't affect you
> since it is a minor release, locate the release notes and see if
I was trying to locate the release notes for 3.6.x it is too old, if I
were you I would update to 3.6.2 (from 3.6.1), it shouldn't affect you
since it is a minor release, locate the release notes and see if
something that is affecting you got fixed, also, I would be thinking on
moving on to 4.x
I have a new question about this issue - I create a filter queries of
the form:
fq=start_time:[* TO NOW/5MINUTE]
This is used to restrict the set of documents to only items that have a
start time within the next 5 minutes. Most of my indexes have millions
of documents with few documents that star
We have a webapp running with a very high HEAP size (24GB) and we have
no problems with it AFTER we enabled the new GC that is meant to replace
sometime in the future the CMS GC, but you have to have Java 6 update
"Some number I couldn't find but latest should cover" to be able to use:
1. Remo
We do perform a lot of sorting - on multiple fields in fact. We have
different kinds of Solr configurations - our news searches do little
with regards to faceting, but heavily sort. We provide classified ad
searches and that heavily uses faceting. I might try reducing the JVM
memory some and amount
My gut instinct is that your heap size is way too high. Try decreasing it to
like 5-10G. I know you say it uses more than that, but that just seems bizarre
unless you're doing something like faceting and/or sorting on every field.
-Michael
-Original Message-
From: Patrick O'Lone [mailto
I am not completely sure about that, but if I remember correctly (it has been
more than one year since I've did that and I was hmm.. whatever you want to
write here, enogh not to take notes :( ), it helped that I've reduced the
percentage of size of permanent generation (somehow, more GC on les
I am not completely sure about that, but if I remember correctly (it has been
more than one year since I've did that and I was lazy enogh not to take notes
:( ), it helped that I've reduced the percentage of size of permanent
generation (somehow, more GC on less permanent gen, but this one is no
14 matches
Mail list logo
