I mean the non latin char I can do without reindex
2018-06-17 16821, 2018
samj1912
I already had it in place
2018-06-17 16828, 2018
samj1912
I just need to adjust the query time boosts
2018-06-17 16836, 2018
samj1912
needed reosarevok's help for it, so I was stalling
2018-06-17 16854, 2018
reosarevok
Need more help?
2018-06-17 16801, 2018
samj1912
reosarevok: yup
2018-06-17 16801, 2018
reosarevok
Ok what help :D
2018-06-17 16825, 2018
samj1912
can you help me with accented searches and punctuation type searches
2018-06-17 16837, 2018
samj1912
like ", @ # $" chars like these
2018-06-17 16849, 2018
samj1912
and non latin chars
2018-06-17 16827, 2018
samj1912
also reosarevok do we need those punctuation searches in other entities?
2018-06-17 16830, 2018
samj1912
or just artists?
2018-06-17 16845, 2018
reosarevok
I'm sure there's at least one label called "+-!" or whatever, because people
2018-06-17 16857, 2018
samj1912
sigh
2018-06-17 16805, 2018
samj1912
so all of the entities?
2018-06-17 16823, 2018
reosarevok
Well, I'd hope area is safe :p
2018-06-17 16823, 2018
samj1912
we will have to rebalance the boosts
2018-06-17 16836, 2018
reosarevok
Instrument too
2018-06-17 16852, 2018
samj1912
those dont matter much in terms of reindexing
2018-06-17 16855, 2018
reosarevok
But there's definitely releases, recordings, rgs which are all punctuation
2018-06-17 16801, 2018
samj1912
ah
2018-06-17 16803, 2018
samj1912
the main ones :P
2018-06-17 16826, 2018
samj1912
ill have to take solr down then :P
2018-06-17 16828, 2018
samj1912
let me do all the schema improvements
2018-06-17 16832, 2018
samj1912
then I will re-index
2018-06-17 16846, 2018
samj1912
reosarevok: you available today?
2018-06-17 16859, 2018
samj1912
I might need your help once the index is done and we are fixing boosts
2018-06-17 16807, 2018
reosarevok
Should be, most of the time, if given a bit of advance notice :)
2018-06-17 16852, 2018
samj1912
cool
2018-06-17 16839, 2018
samj1912
ill start working on the improved schema then
2018-06-17 16809, 2018
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.
2018-06-17 16829, 2018
zas
there are differences in number of threads and disk reads
2018-06-17 16832, 2018
ruaok
I've noticed similar things on other VMs.
2018-06-17 16850, 2018
ruaok
I would suggest getting a new VM and not releasing the old one. see if the new one is more performant.
2018-06-17 16803, 2018
ruaok
OR report the issue to hetzner.
2018-06-17 16821, 2018
ruaok
maybe do a rudimentary performance check and submit the results to them?
2018-06-17 16829, 2018
zas
i noted solr1 isn't IBRS (cpu) while others are
2018-06-17 16858, 2018
zas
IBRS is a cpu fix for spectre and meltdown
2018-06-17 16823, 2018
zas
yes, i'll do that, just wanted to know if you experienced the same
because mb1 = same price of mb2, but twice faster...
2018-06-17 16831, 2018
samj1912
so it was the vm difference after all?
2018-06-17 16854, 2018
D4RK-PH0ENiX has quit
2018-06-17 16833, 2018
zas
it seems
2018-06-17 16829, 2018
D4RK-PH0ENiX joined the channel
2018-06-17 16807, 2018
zas
i sent a support request about this, let's see what hetzner answers.
2018-06-17 16808, 2018
zas
We could try to deploy new VMs and test them and keep best performing ones. Still i'd like an official and technical explanation.
2018-06-17 16826, 2018
samj1912
okay
2018-06-17 16851, 2018
zas
note that results ratio are matching load ratios we have. mb1 > mb3 > mb2
2018-06-17 16811, 2018
zas
and that's also what we have with timings
2018-06-17 16857, 2018
github joined the channel
2018-06-17 16857, 2018
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
2018-06-17 16857, 2018
github has left the channel
2018-06-17 16845, 2018
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.
2018-06-17 16804, 2018
zas
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
2018-06-17 16824, 2018
zas
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
