Hi all,
Had a question about how parameters are combined/overlaid in the JSON
Query DSL. Ran into some behavior that struck me as odd/maybe-buggy.
The query DSL allows params to be provided a few different ways:
1. As query-params in the URI (e.g. "/select?fq=inStock:true")
2. In the JSON reques
Hi Tim and Rohan,
Really appreciate your help, and I finally made it work (without tess4j).
It was the path-environment variable which had a wrong setting. Instead setting
the path of TESSDATA_PREFIX to 'Tesseract-OCR/tessdata' I changed it to the
parent folder 'Tesseract-OCR' and now it works
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 seg
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, Parag
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
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 i
On Fri, Oct 26, 2018 at 10:38 AM Xiaolong Zheng <
xiaolong.zh...@mathworks.com> wrote:
Hi,
But when things come to Solr world which in a Java Webapp with servlet
dispatcher. Do we also keep reusing the same IndexSearcher instance as long
as there is no index changing?
Yes. The IndexSearcher is
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
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 w
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 Unde
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 thr
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?
>
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 d
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 l
14 matches
Mail list logo
