On Sun, Aug 14, 2011 at 8:33 PM, DaB. <WP(a)daniel.baur4.info> wrote: I was using eswiki, but apparently that got split off to s7 months ago. Does anybody have a good suggestion what wiki to use for s3? dawiki is the largest wikipedia on it, but I think it will have very little edits during the night in Europe. I've currently set it to simplewiki, but that isn't a very active one either. Bryan

On Sun, Aug 14, 2011 at 8:12 PM, DaB. &lt;WP(a)daniel.baur4.info&gt; wrote: Update: I seem to be getting the vast majority of mails about "z-dat-s4-a". Replag is <1000s but it seems strange that that one shows up so predominantly.

On Mon, Aug 15, 2011 at 1:30 AM, DeltaQuad Wikipedia &lt;deltaquadwiki(a)gmail.com&gt; wrote: It's not 'the killer', but it might be related, because I got those as well, first time ever: Unable to run job: got no response from JSV script "/sge62/default/common/jsv.sh". Magnus

On Tue, Aug 16, 2011 at 7:03 AM, Maarten Dammers &lt;maarten(a)mdammers.nl&gt; wrote: It was re-enabling a service that has been around for a long time that [accidently] broke at one stage and because of the TS performance not being degraded was never really noticed or cared about. Recently a TS box went down and caused major issues (Replag was easily over 2 days at one stage for those databases) for the backup box handling the effected databases, DaB was monitoring this by hand and manually killing the processes to keep this somewhat saner then re-wrote and brought the tool back online to handle this when they noticed it was [the tool] was not functioning. This was a tool that was already meant to be running but by [your] "luck" wasn't, and was already documented on wiki as DaB pointed out over a year ago. Perhaps you should consider apologizing to DaB in regards to the tone of your email.

Hello, At Tuesday 16 August 2011 23:12:09 DaB. wrote: of corse I considered that users will start inserting SLOW_OK just everywhere before I re-wrote the killer. Let me tell you why that is not so bad as it seems: Most user will not do this because their queries are executed fast enough already (and so the killer ignores them). Some users will add a SLOW_OK, but set a LIMIT: too (that is ok, because the ideas behind SLOW_OK is that users say "I know that will runs longer"). Some user will just add a SLOW_OK because they know that the queries will run for longer (that's ok too). Only very few users will add SLOW_OK to queries which could run fast; and these few queries I can kill manualy and then write angry mails to the users. The query-killer should kill 3 types of queries: -Queries which have a LIMIT: and have run too long, -Queries which run normaly very fast, but for some reason not this time (like an editcounter which works fast for people with low and middle editcounts, but fails for a bot with 100,000 edits) -Queries of users who do not think. If you know that a query will run for longer (because it is complex, because it will return many rows, or something else), then add SLOW_OK (and a LIMIT: if you can) and everything is fine! If you know that the query should run fast, then please set a LIMIT: and look for it if you get too many emails, because something is wrong then. I guess most times (when the replag is low) most users will get no eMails at all (1h is a long time). Sincerly, DaB. P.S: And yes, I can understand if somebody is angry if his/her query is killed. But please try to understand my side too. -- Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885