Looks like SLOW_OK mark is not recognized for INSERT queries.
The query below is marked as SLOW_OK, but unlike to SELECT like queries, report shows just space doubled where the mark was set.
All tables in the query below are user tables, I cannot imaging which way such a query would cause any replag increase.
mashiah
On Sun, Nov 6, 2011 at 2:40 AM, no-reply@toolserver.org wrote:
Hello mashiah, a MySQL-query of yours was killed because you didn't mark it as SLOW_OK and it have run for 609 seconds which was longer than allowed. You can find the query below. Please have also a look at [1] to find information how you can avoid killings of your queries. Maybe you can optimze the query too? The replication lag at kill-time was 121s.
Sincerly, Query-Killer. This eMail was sent automaticaly, please don't reply.
INSERT INTO lwl (lwl_id) SELECT l_from as lwl_id FROM l WHERE NOT EXISTS ( SELECT a2cr_to, a2cr_from FROM a2cr WHERE a2cr_to=l_to and a2cr_from=l_from )
[1] https://wiki.toolserver.org/view/Database_access#Slow_queries_and_the_query_...
Hi Mashiah,
On 5 November 2011 23:48, Mashiah Davidson mashiah.davidson@gmail.comwrote:
Looks like SLOW_OK mark is not recognized for INSERT queries.
The query below is marked as SLOW_OK, but unlike to SELECT like queries, report shows just space doubled where the mark was set.
How did you send the query to the server? There might be a comment stripper somewhere between your query and mysql. Could you post any relevant bits of code?
Merlijn
How did you send the query to the server? There might be a comment stripper
I do that cat'ing a file on stdin of mysql command line client. SELECT queries being killed always contain my SLOW_OK in query killer's message body, and this INSERT does not.
One more interesting message from query killer I've received today, it's body:
--------------------------------------------------- Hello mashiah, a MySQL-query of yours was killed because you didn't mark it as SLOW_OK and it have run for 606 seconds which was longer than allowed. You can find the query below. Please have also a look at [1] to find information how you can avoid killings of your queries. Maybe you can optimze the query too? The replication lag at kill-time was 74s.
Sincerly, Query-Killer. This eMail was sent automaticaly, please don't reply.
DROP TABLE part_pl ---------------------------------------------------
part_pl is a memory table, which by default cannot be too huge due to limited memory allowed for memory tables.
mashiah
toolserver-l@lists.wikimedia.org