<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>Hey everyone,<br><br></div>We just had our regular backend catch-up. It was not recorded but I did take some stream-of-consciousness notes on what we discussed:<br></div><br></div>* train 74 was cut on time!<br><br></div>* but the deploy doc was empty!<br></div>  * a db migration was not mentioned<br></div>  * some config changes weren't mentioned<br></div>  * we should all try to remember to keep the deploy doc up to data as we go<br></div><br>* oauth token purging<br></div>  * on the back burner at the moment, last worked on a few weeks ago<br></div>  * currently up to november 2015, which contains twice as many tokens for some reason<br></div>  * were 500s returned on requests from profile server?<br><br>* verification reminders disabled<br></div><div><div><div><div><div><div><div><div><div><div><div><div>  * no smoking gun except replication couldn't keep up<br>  * replication thread spending most time in system-locked state<br>  * there was a transaction that had millions of rows locked<br>    * stored procedures make it difficult to see exactly what the problem is<br>    * once that transaction unwinds, everything returns to a good state<br></div><div>  * it's recommended not to use temporary tables with replication, is that the issue?<br></div><div>  * or could it be something to do with select for update?<br></div><div>  * do we need a consensus protocol for competing processes?<br></div><div>  * we don't actually need verification reminders running on all instances anyway<br></div><div>    * only needs to be 1 query every 30 seconds<br></div><div>    * with replication we're making a query every second<br></div><div>    * no need to compete<br></div><div>  * what are the release mechanics if we limit it to 1 instance?<br><br></div><div>* teamcity permissions<br>  * deployed a box to try out teamcity 10 with github integration<br></div><div>  * it wants write permissions to the github org, including private repos<br></div><div>  * means the teamcity box would need serious hardening<br>  * what if there's a zero-day exploit in teamcity?<br></div><div>  * vlad's going to email teamcity<br><br>* sentry<br>  * deployed with train 73 content server<br>  * where are all the errors?<br>    * only two errors reported, one from git clone, one from git fetch<br>    * "<path>/experiments already exists and is not empty"<br>  * if things go wrong it should show up there<br><br></div><div>* profile server<br></div><div>  * docker stack is slow, seeing 4-10 times higher latency than non-docker<br></div><div>    * seconds of latency<br></div><div>  * cpu is only a little bit higher<br></div><div>  * also docker stack never returns a 304 for /v1/profile<br></div><div>    * usually there are around 4% or 5% 304s<br></div><div>    * absolute dead zero inside docker<br></div><div>    * how the heck can docker affect this?<br></div><div>    * etag-related?<br></div><div>    * maybe a significant clue of where the slowness comes from<br>  * try disabling all logging so there is no disk i/o, will that fix the latency?<br>    * log data is handled differently in docker<br></div><div>    * different centos version, different log flow, uses systemd and journald<br></div><div>  * one of the devs to try running in docker locally to debug the 304 issue<br></div><div><br>* profile server avatars<br>  * only one avatar per user<br>  * drop some tables<br>  * content server should have no more code for get-avatars api<br>  * if the endpoint is not being elsewhere (it shouldn't be), we should get rid of it<br><br></div><div>And that was it.<br><br></div><div>Cheerio,<br></div><div>Pb<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div>