[00:01:29] * halfak looks forward to making observations about this claim [00:01:39] oh my god I'm an idiot :/ [00:01:50] K4 is ~7,000 miles away and I've locked my keys in the basement [00:02:00] oh crap [00:02:01] ....whelp, time to get my lockpicks. Oh joy this'll be fun [00:02:09] You have picks? [00:02:13] "no, neighbour, this is my house, I promise! Why am I breaking into it, you say? Well.." [00:02:23] yeah, locksport is fun [00:02:30] it's the one thing I do with 'sport' in the name. [00:02:48] How about "if I were a burgler, I'd have stabbed you by now." [00:02:52] my nice set is in the basement but my crappy don't-mind-if-it-gets-taken-away-from-me travel set is up here. This'll be fun [00:02:54] actually this is oakland [00:02:57] I'd probably have shot them [00:20:05] So Ironholds, I'm guessing "Oakland" is the reason that you haven't given one of your neighbors a key as well, right? [00:21:37] yup [00:21:46] although anne gomez has one and if I can't get in I may ask her to swing by tomorrow [00:25:34] You could falcon punch the door too. You know--if you are impatient. [00:32:02] hah [23:14:49] halfak: I'm wondering if we should just launch this at the Research Hackathon, or if that'll be weird. Monday I'll be on a flight until 7PM UK time, and then I'll probably be too tired to do anything productive.... [23:49:24] YuviPanda, I think that's a fine idea. [23:50:04] It's gonna be a hit. I think everyone at the hackathon is going to be trying it out. [23:50:26] :D [23:51:26] halfak: I wonder if I should find ways to simulate load beforehand. [23:51:31] halfak: or if I should work on adding 'fork' [23:52:15] halfak: also, I just deployed a feature that'll stop the previous query run if the query is edited and run again before the previous one completed. I can easily add an explicit 'stop' if I want to, wonder if I should. [23:53:29] I think that people will find the "stop" intuitive and that they'll help bring down server load, but it might be a good idea to run some tests too. [23:53:40] I have some heavyweight queries that we could try. [23:54:09] I have some that will try to make a big temp table and others that will try to put a lot of indexes into memory. [23:54:11] halfak: sure! But the query killer will take care of that, so what we should do is run a *lot* of heavy weight queries in parallel and see how it goes. [23:54:21] Exactly [23:54:48] halfak: right, those probably won't stress test any part of quarry. what we need is queries that simply run for way too long - some by dint of having a very large result set, and some otherwise [23:55:13] halfak: just have one each of each type, submit a 100 of each, and see what happens :) [23:55:33] +1 Do you know when labs is running the fewest queries. [23:55:49] s/./? [23:56:02] halfak: I've it currently set to execute 24 queries in parallel at the same time, and I can potentially increase it up to 64 - 128 per machine, since all these are IO bound and not CPU bound at all [23:56:39] Rather, when it would harm the fewest people if we stressed the DB server for a few minutes? [23:57:10] halfak: good question. I'd say US and European night [23:57:36] Can we effectively assess the load without risking an outage? [23:57:50] halfak: closest we can do is look at ganglia load on those boxes [23:57:55] halfak: and back off if it's too much [23:58:09] Makes sense. [23:58:26] That stop button might come in handy. [23:58:41] halfak: heh :D I have a 'master' stop button, which is just ctrl-c on the server ;) [23:59:01] halfak: but yeah, I'll add it. currently making the query killer more robust [23:59:11] halfak: also, is quarry.wmflabs.org/query/runs/all intuitive at all now? [23:59:27] halfak: I guess I should only show the lastest run for each query?