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