0:16 AM
apetresc has quit
0:25 AM
apetresc joined the channel
0:35 AM
d4rkie has quit
0:36 AM
Nyanko-sensei joined the channel
1:00 AM
BestSteve has quit
1:01 AM
BestSteve joined the channel
3:04 AM
thomasross joined the channel
4:22 AM
thomasross has quit
4:43 AM
blinky42 has quit
5:16 AM
Nyanko-sensei has quit
5:24 AM
Nyanko-sensei joined the channel
5:54 AM
Nyanko-sensei has quit
6:04 AM
Nyanko-sensei joined the channel
7:04 AM
supersandro2000 joined the channel
7:17 AM
_lucifer
7:18 AM
It seems like it is treating my desktop browser as a mobile
7:33 AM
BrainzGit
7:33 AM
BrainzBot
7:34 AM
BrainzGit
7:34 AM
BrainzBot
7:34 AM
BrainzGit
7:34 AM
BrainzBot
7:35 AM
BrainzGit
7:35 AM
BrainzBot
7:47 AM
d4rkie joined the channel
7:48 AM
Nyanko-sensei has quit
7:48 AM
d4rkie has quit
7:58 AM
Nyanko-sensei joined the channel
8:03 AM
yvanzo
_lucifer: how odd?
8:03 AM
I don't have any issue with it at least.
8:04 AM
_lucifer
8:05 AM
This is how it shows up on my PC yvanzo
8:05 AM
probably it is some misconfigured setting then
8:05 AM
on y end
8:05 AM
*my
8:28 AM
Rotab
reset your zoom
8:31 AM
adhawkins
Hi all. Seeing fairly regular OOM reports on my VM running MBserver under docker. Not generating search indexes. VM has 4 Gig of RAM and 2 processors.
8:31 AM
Is this expected? 4 Gig is the recommended configuration I seem to recall?
8:45 AM
ruaok
moin adhawkins. 4gig seems rather paltry for a VM. Go for 8 and I think you'll see some problems go awa.
8:45 AM
away even
8:47 AM
yvanzo
If OOM occurs in db container, you can try increasing shared_buffers first.
8:48 AM
adhawkins
yvanzo: How would I work that out?
8:48 AM
ruaok: 8 Gig would be a quarter of the RAM in the host! :)
8:48 AM
ruaok
only a quarter? fin, 16G then!
8:49 AM
:)
8:49 AM
adhawkins
Wouldn't leave very much for the other VMs :)
8:49 AM
This is only my home setup...
8:50 AM
It's not happening a lot. These are since the VM was booted on 22nd Sept:
8:50 AM
8:53 AM
yvanzo
adhawkins: docker-compose config | grep shared_buffers
8:55 AM
adhawkins
2048M
8:55 AM
yvanzo
but it seems that OOM is invoked on perl, that is musicbrainz server itself, so it's not related to pg shared_buffers.
8:55 AM
adhawkins
I think OOM killer just looks for a candidate process to kill, not necessarily the one that's causing the OOM?
8:55 AM
reosarevok
8:55 AM
I lol'd
8:56 AM
adhawkins
3am is the time I run a local check of my entire library against the server. It usually finishes around an hour or so later.
8:57 AM
yvanzo
8:57 AM
adhawkins
So there will be lots of XML WS requests during the hour between 3am and around 4 ish
8:57 AM
yvanzo
if the problem comes from musicbrainz server itself, there should be hints from `docker-compose logs musicbrainz`
8:58 AM
adhawkins: does your replication cron job run at the same time?
9:00 AM
adhawkins
yvanzo: It runs at around 15 minutes past the hour I think
9:00 AM
yvanzo
every hour?
9:00 AM
adhawkins
Yes
9:01 AM
yvanzo
ok, so there is only one replication packet to be retrieved and applied, that’s better than 24.
9:02 AM
adhawkins
Yes
9:02 AM
I could exclude the hours between say 3 and 6 too, see if that helps?
9:02 AM
yvanzo
You can check slave.log.X for potential errors related to OOM.
9:02 AM
Yes, excluding it during that time could possibly help.
9:05 AM
Gazooo794 has quit
9:05 AM
reosarevok
Mr_Monkey: around?
9:05 AM
Mr_Monkey
Hai !
9:05 AM
adhawkins
Ok, I'll do that as well yvanzo and monitor.
9:06 AM
If I change the replication crontab, what do I need to do to have it applied? Just restart the container?
9:06 AM
Mr_Monkey
Let me guess, wanna talk about dates reo?
9:06 AM
Gazooo794 joined the channel
9:06 AM
BrainzGit
9:06 AM
BrainzBot
9:08 AM
yvanzo
adhawkins: you should check it with crontab -l
9:09 AM
pristine___
ruaok: the travis build stops for some reason, can you have a look?
9:09 AM
yvanzo
you can edit it directly in the container with crontab -e but if you modify it in docker compose config, you need to "up" it (which will stop, remove, recreate a container).
9:09 AM
pristine___
9:10 AM
reosarevok
Mr_Monkey: I do!
9:10 AM
ruaok
heh. travis is being rate limited by github.
9:10 AM
that's tricky
9:10 AM
yvanzo
in any case, check with crontab -l
9:11 AM
reosarevok
So, what do you do with year +0000 ?
9:11 AM
Do you count that as -1 BCE -0001 is -2 BCE etc?
9:12 AM
ruaok
pristine___: other than retriggering the build, not sure what else to do.
9:12 AM
is this for the simple logging changes?
9:12 AM
pristine___
yes
9:12 AM
ruaok
do the tests pass locally?
9:13 AM
yvanzo
reosarevok: year 0 after covid spread? ;)
9:14 AM
Mr_Monkey
So +0000 is year zero AD. The year before that is 1 BCE, which is equal to "-0001" if I remember correctly. There was some complications around year 0, I do remember that, but not the solution. Give me a moment to look that up again
9:14 AM
reosarevok
Mr_Monkey: 0 AD doesn't exist though?
9:15 AM
Mr_Monkey
Ah, that's the one.
9:15 AM
adhawkins
yvanzo: 'up' doesn't appear to have recreated the container.
9:15 AM
I'll manually down and up it.
9:15 AM
reosarevok
An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[21] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.[22]
9:15 AM
Mr_Monkey
Right. Ideally, you'll ignore year 0.
9:16 AM
reosarevok
To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.[20]
9:16 AM
adhawkins
Which container's crontab should I be checking? musicbrainz-docker_musicbrainz?
9:16 AM
yvanzo
adhawkins: yes: docker-compose exec musicbrainz crontab -l
9:16 AM
reosarevok
The library we use does support years BCE but in this way, so I'm wondering whether to just give the user a BCE vs CE option (defaulting to CE) that on entering massages the year to the appropriate expanded year convention
9:16 AM
(so if they enter 1 BCE it will store as 0000)
9:17 AM
We do date calculations (age and such) so in that sense just skipping 0 would be complicated too
9:17 AM
yvanzo
adhawkins: it recreates container if config changed, but if it is just the content of a bind mount maybe it does not need to recreate the container indeed.
9:17 AM
adhawkins
Ok, crontab hasn't updated, even after docker-compose restart musicbrainz
9:17 AM
reosarevok
bitmap: IIRC your change that caused MBS-10976 was intentional, but what should be done in a case like that edit? :)
9:17 AM
BrainzBot
9:17 AM
Mr_Monkey
You suggestion seems ideal. BCE/AD checkbox or select, and a proper library to massage it in and out of the DB
9:18 AM
I went the other route for BB but I think it will need refactoring
9:18 AM
adhawkins
Ah, now it has. I recall there's a job that runs at startup that applies the new crontab
9:18 AM
yvanzo
Cool!
9:20 AM
Mr_Monkey
reosarevok: Also, if it's relevant, I settled for this format (note the 6 digits for year) ±YYYYYY-MM-DD
9:20 AM
adhawkins
Ok, I've stuck a cron job in the host that'll do the dmesg -T | grep oom and email it to me daily. WIll monitor. Thanks yvanzo
9:22 AM
reosarevok
Mr_Monkey: heh, I think that's more relevant for books than music
9:22 AM
For now I'm planning to stick to 4 digits (+ or -)
9:22 AM
Mr_Monkey
And also possibly relevant (?), I opted for CE / BCE in order to leave christ out of all that.
9:23 AM
Granted, it does say christian, but…
9:23 AM
reosarevok
Yeah, I was going to do that for sure
9:23 AM
Depending on how you read it :p
9:23 AM
or "Common"
9:24 AM
Mr_Monkey
For the diehards who don't wanna let it go, i mean :p
9:24 AM
For the rest of us commoners it'll be a step forward.
9:25 AM
I swear if I ever get a time machine I'll go back and find the dummy who decided there would be no year 0 and give him a talking to.
9:31 AM
pristine___
ruaok: yeah, tests pass on dev
9:33 AM
ruaok
then I'm fine to merge and push to newleader.
9:33 AM
shall I do that?
9:36 AM
pristine___
Yeah, there are only log changes. I think you can push to newleader
9:37 AM
BrainzGit
9:39 AM
ruaok
pristine___: done.
10:00 AM
pristine___
10:01 AM
ruaok: ^
10:09 AM
ruaok
it increased 19 fold? O_O
10:10 AM
pristine___
listen count increases joining with mapping. i didn't expect that
10:10 AM
writing few more log statements to understand what's happening.
10:10 AM
ruaok
yes, please. this sounds like a query mistake; some join going bad.
10:11 AM
it should be less than the original amount, best case equal, no?
10:12 AM
pristine___
> it should be less than the original amount, best case equal, no?
10:12 AM
yes!
10:34 AM
BrainzGit
10:34 AM
BrainzBot
10:50 AM
pristine___
10:52 AM
this is apparently causing that 19 fold increase! We should first filter all the distinct rows from the mapping and then perform the join.
10:52 AM
ruaok: ^
10:53 AM
d4rkie joined the channel
10:54 AM
ruaok
yep, that would do it. :)
10:55 AM
pristine___
removing `msb_recording_msid| msb_recording_name_matchable| msb_release_msid| msb_release_name_matchable`from the mapping before the join will do
10:55 AM
supersandro2000 has quit
10:55 AM
`msb_recording_msid|msb_release_msid|msb_release_name_matchable`