Thanks Erick, appreciate your help
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
To add to Daniel's comments: Are you indexing at the same time? Say
your autocommit time is 10 seconds. For the sake of argument let's say
it takes 15 queries to warm your searcher. Let's further say that the
average time for those 15 queries is 500ms each and once the searcher
is warmed the
No best practices as such, "whatever works" about covers it. That's
not a huge query rate, especially if you have replicas per shard so I
wouldn't worry too much about it. If you rack 100 clients all driving
Solr as hard as possible and people complain that query responses are
bad you'll know
Java 9 hasn't been proven at this point, so I'd be reluctant to
recommend it under any circumstances. Java 11 is probably going to be
the next recommended version, but there are some outstanding issues.
Lots of clients I know are using G1 at this point.
Best,
Erick
On Wed, Oct 24, 2018 at 3:05
We’ve been running 1.8.0_131 with G1 in prod for well over a year, on 30-50
hosts.
We actually got a SIGSEGV in a JVM two days ago, but that has been the only
error. AWS had scheduled a reboot for that some host by tomorrow, so it might
have been a hardware issue.
wunder
Walter Underwood
Hey Solr Users,
I'm curious what the state of Solr/Lucene is with the G1 garbage
collector. specifically Solr 6.6.5 & 7.5.0 and JDK8/9? I know that
there have been issues previously that caused Lucene's test suites to
randomly fail with G1, but all of the known issues are resolved as far as I
Thanks Erick, that's extremely insightful. I'm not using batching and that's
the reason I was exploring ConcurrentUpdateSolrClient. Currently, N threads
are reusing the same CloudSolrClient to send data to Solr. Ofcourse, the
single point of failure was my biggest concern with
Usually, responses are due to I/O waits getting the data off of the disk. So,
to me, this seems more likely because as you bombard the server with queries,
you cause more and more of the data needed to answer the query into memory.
To verify this, I'd bombard your server with queries to warm
We are currently using Solr Cloud Version 7.4 with SolrJ api to fetch data
from collections. We recently deployed our code to production and noticed
that response time is more if the number of incoming requests are less.
But strangely, if we bombard the system with more and more requests we get
I wouldn't use ConcurrentUpdateSolrClient for the following reasons:
1> If a doc that needs to go to shard2 is received by a replica on
shard1, it must be forwarded to the leader of shard1, introducing an
extra hop. CloudSolrClient subdivides the batch and sends the docs to
the leader of the
Hi,
I'm looking into the possibility of using ConcurrentUpdateSolrClient for
indexing a large volume of data instead of CloudSolrClient. Having an
async,batch API seems to be a better fit for us where we tend to index a
lot of data periodically. As I'm looking into the API, I'm wonderign if
Are you getting errors in Jmeter?
On Wed, 24 Oct 2018, 21:49 Amjad Khan, wrote:
> Hi,
>
> We recently moved to Solr Cloud (Google) with 4 nodes and have very
> limited number of data.
>
> We are facing very weird issue here, solr cluster response time for query
> is high when we have less
The merge can be really fast - it can just dump in the new segments and
rewrite the segments file basically.
I guess for you want, that's perhaps not the ideal route though. You could
maybe try and use collection aliases.
I thought about adding shard aliases way back, but never got to it.
On
If your cache is 2048 entries, then every one of those 1600 queries is in cache.
Our logs typically have about a million lines, with distinct queries
distributed according to the Zipf law. Some common queries, a long tail, that
sort of thing.
wunder
Walter Underwood
wun...@wunderwood.org
But a zero size cache doesn’t give realistic benchmarks. It makes things slower
than they will be in production.
We do this:
1. Collect production logs.
2. Split the logs into a warming log and and a benchmark log. The warming log
should be at least as large as the query result cache.
3. Run
Thanks Erick,
But do you think that disabling the cache will increase the response time
instead of solving the problem here.
> On Oct 24, 2018, at 12:52 PM, Erick Erickson wrote:
>
> queryResultCache
Thanks Wunder for this prompt response.
We are testing with 1600 different text to search with Jmeter and that keeps
running continuously, and keep running continuously means cache has been built
and there should be better response now. Doesn’t it?
Thanks
> On Oct 24, 2018, at 12:20 PM,
You can set your queryResultCache and filterCache "size" parameter to
zero in solrconfig.xml to disable those caches.
On Wed, Oct 24, 2018 at 9:21 AM Walter Underwood wrote:
>
> Are you testing with a small number of queries? If your cache is larger than
> the number of queries in your
Are you testing with a small number of queries? If your cache is larger than
the number of queries in your benchmark, the first round will load the cache,
then everything will be super fast.
Load testing a system with caches is hard.
wunder
Walter Underwood
wun...@wunderwood.org
Hi,
We recently moved to Solr Cloud (Google) with 4 nodes and have very limited
number of data.
We are facing very weird issue here, solr cluster response time for query is
high when we have less number of hit and the moment we run our test to hit the
solr cluster hard we see better response
bq. I've noticed that some replicas stop receiving updates from the
leader without any visible signs from the cluster status.
Hmm, yes, this isn't expected at all. What are you seeing that causes
you to say this? You'd have to be monitoring the log for update
messages to the replicas that aren't
You could use something like AtomicUpdateProcessorFactory:
https://lucene.apache.org/solr/guide/7_5/update-request-processors.html#atomicupdateprocessorfactory
Regards,
Alex.
On Wed, 24 Oct 2018 at 04:48, Zahra Aminolroaya wrote:
>
> Does Solr have a partial update like elastic?
>
> Elastic
First one treats space as end of operation, so the second keyword is
searched against default field (id). Try putting the whole thing into the
quotes. Or use Field Query Parser:
https://lucene.apache.org/solr/guide/7_5/other-parsers.html#field-query-parser
Regards,
Alex.
On Wed, Oct 24, 2018,
Thanks to you both. Did not take the time to look into yet. I will.
Eric.
Sent from my Samsung Galaxy smartphone.
Original message From: Erick Erickson
Date: 2018-10-24 00:57 (GMT-05:00) To: solr-user
Subject: Re: Join across shards?
In addition to Vadim's comment, Solr
Hi All !
I'm testing Solr 7.5 with TLOG replicas on SolrCloud with 5 nodes.
My collection has shards and every shard has 3 TLOG replicas on different
nodes.
I've noticed that some replicas stop receiving updates from the leader
without any visible signs from the cluster status.
(all replicas
Hi,
I'm having troubles with the filter query on a multiple string field,
specifically with a space between words. Looking at the histogram and
values using Solr UI it correctly shows that the indexing stores the
string "Key case" as it should. However the following filter queries:
Does Solr have a partial update like elastic?
Elastic will automatically merge new document with the existing one having
the same id. For example if the new document has a value for field that it
was previously null, it will add the value for that field.
However, based on what I found,
Thanks Alexandre and Shawn.
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Please check if there is a deadlock happening by taking heap dumps
Deepak
"The greatness of a nation can be judged by the way its animals are
treated. Please consider stopping the cruelty by becoming a Vegan"
+91 73500 12833
deic...@gmail.com
Facebook: https://www.facebook.com/deicool
29 matches
Mail list logo
