bq. Do you really think running a profiler on 4.4 will be more
effective than upgrading to 7.x?
No but it's better than random speculation.
On Sun, Oct 28, 2018 at 9:34 PM Deepak Goel wrote:
>
> What are your hardware utilisations (cpu, memory, disk, network)?
>
> I think you might have to tune
What are your hardware utilisations (cpu, memory, disk, network)?
I think you might have to tune lucene too
On Wed, 26 Sep 2018, 14:33 Mugeesh Husain, wrote:
> Hi,
>
> We are running 3 node solr cloud(4.4) in our production infrastructure, We
> recently moved our SOLR server host softlayer to
Do you really think running a profiler on 4.4 will be more effective than
upgrading to 7.x?
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Oct 28, 2018, at 8:53 PM, Erick Erickson wrote:
>
> Put a profiler on it and see where the hot spots are?
>
Put a profiler on it and see where the hot spots are?
On Sun, Oct 28, 2018 at 8:27 PM Walter Underwood wrote:
>
> Upgrade, so that indexing isn’t using as much CPU. That leaves more CPU for
> search.
>
> Make sure you are on a recent release of Java. Run the G1 collector.
>
> If you need more
Upgrade, so that indexing isn’t using as much CPU. That leaves more CPU for
search.
Make sure you are on a recent release of Java. Run the G1 collector.
If you need more throughput, add more replicas or use instance with more CPUs.
Has the index gotten bigger since the move?
wunder
Walter
The original question though is about performance issue in the Searcher.
How would you improve that?
On Sun, Oct 28, 2018 at 4:37 PM Walter Underwood
wrote:
> The original question is for a three-node Solr Cloud cluster with
> continuous updates.
> Optimize in this configuration won’t help, it
The original question is for a three-node Solr Cloud cluster with continuous
updates.
Optimize in this configuration won’t help, it will just cause expensive merges
later.
I would recommend updating from Solr 4.4. that is a very early release for
Solr Cloud. We saw dramatic speedups in indexing
Well, if you optimize on the master you'll inevitably copy the entire
index to each of the slaves. Consuming that much network bandwidth can
be A Bad Thing.
Here's the background for Walter's comment:
https://lucidworks.com/2017/10/13/segment-merging-deleted-documents-optimize-may-bad/
Solr 7.5
What would you do if your performance is degrading?
I am not suggesting doing this for a serving index. Only one at the Master,
which ones optimized gets replicated. Am I missing something here?
On Sun, Oct 28, 2018 at 11:05 AM Walter Underwood
wrote:
> Do not run optimize (force merge) unless
Do not run optimize (force merge) unless you really understand the downside.
If you are continually adding and deleting documents, you really do not want
to run optimize.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Oct 28, 2018, at 9:24 AM,
Hi Mugeesh,
Have you tried optimizing indexes to see if performance improves? It is
well known that over time as indexing goes on lucene creates more segments
which will be searched over and hence take longer. Merging happens
constantly but continuous indexing will still introduce smaller
Hi,
We are running 3 node solr cloud(4.4) in our production infrastructure, We
recently moved our SOLR server host softlayer to digital ocean server with
same configuration as production.
Now we are facing some slowness in the searcher when we index document, when
we stop indexing then searches
12 matches
Mail list logo
