I mean the non latin char I can do without reindex
I already had it in place
I just need to adjust the query time boosts
needed reosarevok's help for it, so I was stalling
reosarevok
Need more help?
samj1912
reosarevok: yup
reosarevok
Ok what help :D
samj1912
can you help me with accented searches and punctuation type searches
like ", @ # $" chars like these
and non latin chars
also reosarevok do we need those punctuation searches in other entities?
or just artists?
reosarevok
I'm sure there's at least one label called "+-!" or whatever, because people
samj1912
sigh
so all of the entities?
reosarevok
Well, I'd hope area is safe :p
samj1912
we will have to rebalance the boosts
reosarevok
Instrument too
samj1912
those dont matter much in terms of reindexing
reosarevok
But there's definitely releases, recordings, rgs which are all punctuation
samj1912
ah
the main ones :P
ill have to take solr down then :P
let me do all the schema improvements
then I will re-index
reosarevok: you available today?
I might need your help once the index is done and we are fixing boosts
reosarevok
Should be, most of the time, if given a bit of advance notice :)
samj1912
cool
ill start working on the improved schema then
zas
ruaok: we have an huge performance difference between solr1 and solr2/3, while they receive same amount of queries and output same amount of data, solr 1 load is much lower.
there are differences in number of threads and disk reads
ruaok
I've noticed similar things on other VMs.
I would suggest getting a new VM and not releasing the old one. see if the new one is more performant.
OR report the issue to hetzner.
maybe do a rudimentary performance check and submit the results to them?
zas
i noted solr1 isn't IBRS (cpu) while others are
IBRS is a cpu fix for spectre and meltdown
yes, i'll do that, just wanted to know if you experienced the same
because mb1 = same price of mb2, but twice faster...
samj1912
so it was the vm difference after all?
D4RK-PH0ENiX has quit
zas
it seems
D4RK-PH0ENiX joined the channel
i sent a support request about this, let's see what hetzner answers.
We could try to deploy new VMs and test them and keep best performing ones. Still i'd like an official and technical explanation.
samj1912
okay
zas
note that results ratio are matching load ratios we have. mb1 > mb3 > mb2
and that's also what we have with timings
github joined the channel
github
[acousticbrainz-server] paramsingh closed pull request #275: AB-343: Move number of recordings fetched per batch into config.py (musicbrainz-integration-gsoc...move2config) https://git.io/vh1xA
github has left the channel
zas
i found out that echo 2 > /proc/sys/kernel/ibrs_enabled gives better result on solr2/3 (~15% faster), but we can't get the same perf than on solr1. I think the patched cpu (IBRS) is the cause.
solr2 & 3 are on par with same values in /proc/sys/kernel/ibrs_enabled (2) and /proc/sys/kernel/ibpb_enabled (0), and they perform a tad better
samj1912: let's do another stress test, one with ibpb=1 and ibrs=0 (worse results), and another with ibpb=0 and ibrs=2 (best results), to see if it is confirmed by graphs