#metabrainz

morning o/

moooin \o/

moooin! -ø/

ruaok: about SOLR-84

SOLR-84: Search for !!! artist returns no results https://tickets.metabrainz.org/browse/SOLR-84

I can fix it, but it might require a reindex

s/might/will

forgot about it

see if there are other issues that need fixing before you reindex...

ruaok: https://tickets.metabrainz.org/projects/SOLR/is...

just the non latin char improvements

I fixed/closed most of the tickets

k, then lets do those two and reindex.

okay

ruaok: just for artist?

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

Need more help?

reosarevok: yup

Ok what help :D

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?

I'm sure there's at least one label called "+-!" or whatever, because people

sigh

so all of the entities?

Well, I'd hope area is safe :p

we will have to rebalance the boosts

Instrument too

those dont matter much in terms of reindexing

But there's definitely releases, recordings, rgs which are all punctuation

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

Should be, most of the time, if given a bit of advance notice :)

cool

ill start working on the improved schema then

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

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?

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

yep, I had.

the difference is very obvious in our case

response time is half on solr than on others

basically mb1=240 ops, mb2=120 ops, mb3=160 ops

i'll ask hetzner about it

because mb1 = same price of mb2, but twice faster...

so it was the vm difference after all?

it seems

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.

okay

note that results ratio are matching load ratios we have. mb1 > mb3 > mb2

and that's also what we have with timings

[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

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

samj1912: around?

yeah

was working on schema

gimme a moment

zas yes

siege?

nvm i found it;)

i'll run it

okay

use test2 file

reosarevok: ruaok about SOLR-85

SOLR-85: Indexed search syntax partially broken https://tickets.metabrainz.org/browse/SOLR-85

country:xe doesnt work anymore coz it is supposed to be country:Europe now

was the search using iso code always?

yes

ah ok

We translate country names

do you want name search?

oh ok

So code should work, if English names work too that's great, but not 100% needed

I am removing english names then

reosarevok: also what's wrong with the other query?

format:\-

https://musicbrainz.org/search?query=format%3A%... apparently it returns all stuff without a format set

[sir] samj1912 opened pull request #88: SOLR-85: Fix country search (master...fix-country) https://git.io/vhM4A

I didn't know of this one :D

is unknown a string?

that's a super weird syntax

he is escaping the not character

idk why

Lucene probably breaks otherwise

as in?

that is basically searching for a hyphen?

As in a query of "format:-" is just deemed invalid

So it's \- instead

Now, *why* that, I dunno

but I am not getting it why he wants to search for a hyphen

and how that is returning all unknown results?

He wants to search for "stuff with nothing set"

I assume this is the hardcoded shortcut for it

well, its just wrong :P

Well, we need to provide the functionality

I cant see it anywhere in the documentation

why so?

Because it's a useful search

there is a way to search for that

But doing it as "format:unknown" instead is probably better

just not with that paritcular search

that syntax is just plain wrong

I am not even sure how its working