Does anyone know if there's a trick to get /* SLOW_OK */ into a stored procedure? When I create a stored procedure with a /* SLOW_OK */ comment in it, the stored procedure is saved with the comments stripped out.
- Jason
--- On Tue, 8/16/11, toolserver-l-request@lists.wikimedia.org toolserver-l-request@lists.wikimedia.org wrote:
From: toolserver-l-request@lists.wikimedia.org toolserver-l-request@lists.wikimedia.org Subject: Toolserver-l Digest, Vol 70, Issue 10 To: toolserver-l@lists.wikimedia.org Date: Tuesday, August 16, 2011, 5:00 AM
Send Toolserver-l mailing list submissions to toolserver-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/toolserver-l or, via email, send a message with subject or body 'help' to toolserver-l-request@lists.wikimedia.org
You can reach the person managing the list at toolserver-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Toolserver-l digest..."
Today's Topics:
1. Re: [Toolserver-announce] Query-Killer is back in action (Huib Laurens) 2. Re: Query-Killer is back in action (Maarten Dammers) 3. Re: Query-Killer is back in action (DaB.) 4. Re: Query-Killer is back in action (K. Peachey)
----------------------------------------------------------------------
Message: 1 Date: Mon, 15 Aug 2011 17:43:15 +0200 From: Huib Laurens sterkebak@gmail.com Subject: Re: [Toolserver-l] [Toolserver-announce] Query-Killer is back in action To: toolserver-l@lists.wikimedia.org Message-ID: CAGkfB_qcKj=yfB9hTn+oeW1GTJcOo-_uPznmXX1fTrbDB8iCfQ@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1
Is this script somewhere aivable? I would like to use it also outside the toolserver.,
2011/8/15, Magnus Manske magnusmanske@googlemail.com:
On Mon, Aug 15, 2011 at 1:30 AM, DeltaQuad Wikipedia deltaquadwiki@gmail.com wrote:
Quick question, is "Unable to run job: got no response from JSV script "/sge62/default/common/jsv.sh" " The killer? becuase ya, I got a lot of them, came home after about 5 hours to about 8 of them, and my API queries are quick...I don't get (unless it's the server) what i'm doing wrong.
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
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
the linked wiki-page was updated with the information about the query-killer more than 1 year ago.
Sincerly, DaB.
On my view the query killer is indeed a very nice function to ballance between toolserver's force shared to user tools and its (toolserver's) stable operation and overall performance. I just thought once it previously worked in a less restricting way, there was a good reason for higher restrictions just introduced.
Let's take an example of killer's behaviour, which is partially could be considered helpfull and partially questionable:
a MySQL-query of yours was killed because you didn't mark it as SLOW_OK
and it have run for 3612 seconds which was longer than allowed.
I see this as a very helpfull part, which recommends to think of the query optimization or at least on the magic word.
Next,
The replication lag at kill-time was 0s.
and the query itself starts with
DELETE l FROM l, a2cr WHERE l_to=a2cr_to
Each table is local to a user database and used exclusively by a single (TRANSACTION ISOLATION LEVEL READ UNCOMMITTED) thread. This query should not cause any other queries wating for its completion, and as far as replag is zero at the execution time it does not cause any toolserver's resource being unavailable or limited in requested capacity to other users.
Previously the query killer interrupted queries just in case of replag upper some thresold, which is a bit less restrictive condition, but seems not yet the very proper one. It killed all the queries worked for more then allowed and (looked like) did not undertake any smarter analysis on which queries are the most influencing or causing the replag increased.
I assume once the query killer started looking for replag more regularely it could be in a position to mark queries working for long and not causing more or less stable replag increase as more or less safe and wait longer prior to kill them.
mashiah
toolserver-l@lists.wikimedia.org