#musicbrainz-devel

Plan is to keep doing those two things for now

cheers to that!

With some focus in making the guidelines shorter, clearer and (if possible) in less pages :p

But we'll see about that one :)

And that's basically it I think

k, anyone else?

onward. transaction mode. where did we leave off?

do it, but when was the issue, right?

yeah

> maintenance DB needs to go in via server-configs and beta config, then wait a day, then transaction mode, I think?

also, once again this goes back to the pgbouncer issue.

how about we finish all the bits of the schema change and then return to this?

it's orthogonal to the pgbouncer issue, it just needs to be updated in config, wherever the current config is

but yeah, things have been pretty stable, I think we can wait

given that things have been nice and stable,

heh.

ok, motion carried.

nikki: supported browsers.

maintenance mode can of course go in whenever though. might do that sooner if I feel like it

this time round there has been quite a bit of change: safari should go from 5.1 to 7.0, chrome should go from 31 to 39 and firefox should go from 24 to 31 (technically 12 and 21 are popular too, but those are 100% spammers, looking at the urls they're requesting)

ruaok has changed the topic to: It is a week! | Agenda: reviews/general discussion, supported browsers (nikki)

we now have stats for logged in users too. ie is the only one where there's a noticeable difference. while ie8 just won't fucking die, for logged in users, only ie11 makes it above 0.5%. we already have a thing saying we don't support ie8 for editing, my suggestion would be to update it to say that we support ie8+ for logged out stuff and ie11+ for logged in stuff, to match the stats

seems reasonable to me.

+100

sure

motion carried, I guess, you want to update the page, nikki?

sure

anything else for this week?

ruaok has changed the topic to: It is a week! | Agenda: reviews/general discussion

looks like no

right-o, let's close for the week.

thanks everyone!

Blaatkip: how are you doing?

oh

done with the files

did you un jar the war file?

no not yet

ok, do this:

/etc/init.d/jetty stop

I wonder if someone in the world, there's someone honestly writing a blog comment like "It's actually a great and useful piece of information" and then wondering why it never appears

*somewhere

rm -rf /var/lib/jetty/webapps/*

cd /var/lib/jetty/webapps

jar xf <warfile>

/etc/init.d/jetty start

ok

can i delete the wer file after?

war

(aside) re: pgbouncer, the version we're running is actually older than the package version, though the package one seems to be marked 'partially configured'

Blaatkip: ya.

now run reindex.

and that will take till tomorrow?

give a take a few hours

or

depend on your machine. just let it go overnight

how do i start the script lol

he VM comes with support to build search indexes. In order to build the indexes, log in to the account and then: bin/reindex

which account bc i tried a couple and they don't work

guess i'm rly braindead

working now

diddnt b4

:S

ty Alot!

Gentlecat: yes, I did

alastairp: what do you think?

looks like a website ;)

right :D

ruaok: for general awareness -- we're seeing a lot of 502s right now, and pgbouncer has a bunch of waiting stuff, like before; hung processes seem to not really be it, because that's not really the same with this setup, so

I'm HUPing the frontends to see if forcing a restart of processes will help fix it

there are some really old processes though, I notice, hm

Gentlecat: but yeah, if that’s the style, I’m not too concerned about it

I saw you had a bit of feedback

alastairp: feel free to send comments. looks like I've got nothing better to do this night

and we put them pass ruaok or nico

variations of which part? tables?

ianmcorvidae: old processes on. astro & co?

ruaok: yeah, looks like a different way of stuck processes appearing with the new starlet setup

killing those to see if it fixes it

k

oh yeah, really bad now. :(

hm, seems to have done nothing

goes back to your "random brain noise" email. we should really monitor this number.

yeah

how about taking one machine out, restarting the services and then back in?

pgbouncer doesn't actually give you real tables you can query, though, it's just a printed-out table

see if that has any effect?

you don't have to take machines out to restart the services :)

right. nice. :)

(that being what the starlet/server::starter thing gave us)

wait

numbers just dropped quite a bit.

I saw 170s

never mind, back to 158.

fluctuates a bit I see.

yeah, it moves around

go ahead, sorry.

I'd already done it when you said wait, so

ah

Gentlecat: yeah, the borders which you said

what trip? moscow?

man. I didn;t even know you could get jetlag in a single country

yeah

alastairp: have you see the size of that country?

I can drive across my country in an hour

11 timezones!

now it's dropped down a ways

in my view,a ll countries are a similar size

ianmcorvidae: so you've done two of four servers now?

back up.

people who live on the east coast of the US are that way about states and get very confused when they go west :P

yeah.

asterix/pingu done, lolo/astro not touched other than killing old/stuck processes

after restarting asterix/pingu some of the just-killed processes seem to stick around a while, so I've also been cleaning those up immediately

are we certain that the starlet/server::starter actually takes care of these dead procs?

it's supposed to, but the switch was done so we could reprovision without needing to take things out

alastairp: so I pretty much lived bcn time back home because if our shenanigans. Thought that when I'll get to europe will fit perfectly in that time zone

guess what

starman was supposed to handle that too and didn't :)

ianmcorvidae: yeah, I don't trust magic like that.

502s are on a downswing too, anyway, so something seems to be helping short-term

if manual cleanup doesn't help, we should take them out of rotation and completely stop/start.

you understand that's not doing anything different, right?

the issue here is that these processes don't go away with SIGTERM

and need a kill

which no sanely-written software is going to give it

got it.

how Server::Starter works is it creates new processes and then SIGTERM's the old ones

with them sharing the socket so the handover is smooth

so, the ultimate solution is figuring out why these things get into a state where they need sigkill

it just empties out the current pool and creates new ones, but bit-by-bit?

not really bit-by-bit at all

it creates a whole new pool, switches over the socket, then sends term to everything in the old pool

the cleverness is since it's a parent process it can hand over the socket, basically

vs. doing it manually which would take it down entirely and then rebind the socket to a new parent process

interesting. wouldn't that double the memory footprint for a brief period?

but I think it's clear the problem is somewhere other than this handling, since we had things happening before

maybe not double, but certainly increase abit.

sure, probably increases load for a bit