jsp?p=c2hhcmVkLzIwMjIvMTIvOC9sb2dzLnR4dC0tMTAtNTUtMzA=&;
JVM Settings: We are using Parallel GC, can this be causing this much log
pause?
-XX:+UseParallelGC
-XX:-OmitStackTraceInFastThrow
-Xms12g
-Xmx12g
-Xss256k
What more we can check here to find the root cause and prevent this from
happening again?
Thanks in advance
--
Er
after a while (some days) some cores grow again.
I have upload a COLSTATUS too with information about shard leaders and
their segments.
Any ideas about this issue?
Thanks!
--
Ere Maijala
Kansalliskirjasto / The National Library of Finland
.
Can you suggested if it requires any additional configurations.
We are using Solr 8.8 and Zookeeper 3.6.2.
Heap set to 24 GB
Could has three nodes. Solr and Zookeeper in the same EC2 box.
Thanks in advance.
Regards,
Venkat.
Information Classification: General
--
Ere Maijala
Kansalliskirj
cores higher,
which they will with a plain OR. Likely the original term will score slightly
higher in many cases due to higher IDF.
Jan
26. aug. 2021 kl. 11:26 skrev Ere Maijala :
Hi,
Right, ok.
For an exact match boost to work, you'd have to index into another field with a
different anal
ed some kind of protwords-list for exceptions, we could
start assembling words that we know for sure clashes and should be excepted,
however an exact-match rank boost approach would seem more flexible.
Jan
26. aug. 2021 kl. 10:08 skrev Ere Maijala :
Hi,
For our Finnish audience we avoid f
h different
weights?
Jan
--
Ere Maijala
Kansalliskirjasto / The National Library of Finland
g,
we want to stop it.
wunder
Walter Underwood
wun...@wunderwood.org <mailto:wun...@wunderwood.org>
http://observer.wunderwood.org/ <http://observer.wunderwood.org/>
<http://observer.wunderwood.org/ <http://observer.wunderwood.org/>> (my
blog)
--
Håvard Wahl Kongsgård
Data Scientist
--
Ere Maijala
Kansalliskirjasto / The National Library of Finland
nking-evaluator for
some tooling that can help!
On Apr 29, 2021, at 7:42 AM, Ere Maijala wrote:
Thanks for sharing your experience. We've been running sow=false until now and
got away with it as most searches hit a catch-all field. That won't be the case
in the long run anymore,
upgraded from),
but after adding this my handler things were back to normal.
On Thu, Apr 29, 2021 at 11:45 AM Ere Maijala
wrote:
Ah, yes, that seems to be the case. Thanks for the pointer! Also the
discussion is enlightening. It looks like there hasn't been much
happening in that bug so I
bug
https://issues.apache.org/jira/browse/SOLR-12779
Jan
29. apr. 2021 kl. 08:51 skrev Ere Maijala :
Hello Markus,
Thanks for the reply. I'm not sure I understand. The docs state the following:
"The default value of mm is 0% (all clauses optional), unless q.op is specified as
&qu
ax-query-parser.html
[2] https://solr.apache.org/guide/6_6/the-extended-dismax-query-parser.html
Op wo 28 apr. 2021 om 15:02 schreef Ere Maijala :
Hi,
Here's one that I can't wrap my head around. The main question is: why
are the search terms treated differently in eDisMax if the qu
licated. It has our custom class create the synonyms for compound
words in Finnish, and the queries come from users.
2. As far as I can see mm doesn't affect the results in any meaningful
way, but I just might be doing something wrong.
3. I included the debugQuery parameter so that it's easy to see how
different the queries become.
Best Regards,
Ere
--
Ere Maijala
Kansalliskirjasto / The National Library of Finland
12 matches
Mail list logo