Hello all,
the following message is only interesting for people who uses the MySQL-CLI
(the "mysql"-command on the command-line) or the "sql"-script. It doesn't
matter if you use php, perl, phyton, java or other languages.
The problem is that the mysql-cli strips out comments by default (see
bugreport [1]). That is bad for us, because it strips all SLOW_OK or LIMIT:
too; so if you add a SLOW_OK at the mysql-cli it will stript out and the
query-killer will kill it sooner. To prevent this, I changed the mysql-config
in a way that comments will NOT be stripted yesterday [2] .
In the last hour a user told me, that this has a problematic side-effect: if
you use /* foobar */ in a mysql-file OUTSIDE of a query, the file will fail; the
user was angry because I changed the default without telling.
I still think that the mysql-default (to strip comments) is stupid (because in
my eyes the user doesn't expect that comments he/she inserts will be removed).
So here is my plan: I will revert my changes for now (so the mysql-cli will
strip comments again). And I hereby announce that I'm going to change the
default at wednesday, the 31. August, in a way that comments will NOT the
striped out.
You what that means for you:
-If you don't use comments at the mysql-cli: nothing.
-If you use comments at the mysql-cli: You have to add the following lines to
,your .my.cnf-file (you can find this hidden file in your home – please notice
the "." at the start):
--snip--
[mysql]
comments
--snap--
-If you need the default of the mysql-cli after the 31. August, you have to
add the following lines to your .my.cnf:
--snip--
[mysql]
skip-comments
--snap--
My revert will not affect the "sql"-script (our recommend way to uise myql on
the command-line): It will still not strip the comments.
Please feel free to discuss this and ask for details on the mailinglist.
Sincerly,
DaB.
[1] http://bugs.mysql.com/bug.php?id=26215
[2] https://jira.toolserver.org/browse/MNT-1072
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Several users were worried about toolserver tools that stopped working
without (to them) apparent reason. I have tried to explain in in
non-tech-German [1] and it seems that helped.
I was then asked if these issues are communicated somewhere centrally.
I found [2], which points to [3], which returns 404. It would probably
be too technical anyway. status.toolserver.org would not help the
average user either, even if it were always up-to-date.
So, should issues that affect the toolserver users (either the
code-writing or the tool-using, or both) be mentioned somewhere? There
is the toolserver blog [4], with the last entry from February 2010...
I think if all toolserver admins had write access to that blog, one of
them could spare 5 minutes (if that) to update the general public
about major issues or changes (changing stuff on the toolserver, even
supposedly minor changes, tends to break stuff...).
Cheers,
Magnus
[1] http://commons.wikimedia.org/wiki/Commons:Forum#Zentrale_Info_.C3.BCber_Tec…
[2] http://meta.wikimedia.org/wiki/Toolserver/MaintenanceLog
[3] https://jira.toolserver.org/display/tech/Maintenance+log
[4] http://journal.toolserver.org/
I've just completed the upload of the last 7 missing months of Domas'
usage stats to the Internet Archive from Toolsever:
http://en.wikipedia.org/?diff=442322098&oldid=437346049http://www.archive.org/search.php?query=subject%3A%22Wikimedia%20projects%2…
/mnt/user-store/stats/ lacks 'projectcounts' for some months (before
November 2009, from December 2009 to March 2010 and perhaps something
else) so some IA backups lack them as well.
It would be interesting to understand what happened; moreover, IIRC
there's another copy of the stats on some WMF server, which could be
used to complete the IA public copy and/or the Toolserver copy.
Nemo
Hello all,
during the last week I kept an eye on the database-servers and killed queries
which had run for too long. In the past we had a programm for that, but
somewhen it stoped working and nobody fixed it AFAIK.
Because watching the mytop is a boring thing and I have to sleep too, I used
the last 2-3 days to write a substitute of the old query-kiler. This program
is working now. It does more or less the same as I did, but it send you an
eMail when it killed one of your query. I think that is an improvment and I
can spend my time with other things.
You can find the parameters of when and if the killer works at [1]. Of corse
there is always the possiblity of adjustments. Feel free to open bugs at JIRA
or discuss on teh mailinglist.
Sincerly,
DaB.
[1]
https://wiki.toolserver.org/view/Database_access#Slow_queries_and_the_query…
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
It might be best to turn this off until server 3 no longer thinks
it's *8 months* behind.
----
User:Hersfold
hersfoldwiki(a)gmail.com
Sent from my Windows Phone From: Magnus Manske
Sent: Sunday, August 14, 2011 13:51
To: toolserver-l(a)lists.wikimedia.org
Subject: Re: [Toolserver-l] Query-Killer is back in action
On Sun, Aug 14, 2011 at 5:42 PM, DaB. <WP(a)daniel.baur4.info> wrote:
> Hello all,
>
> during the last week I kept an eye on the database-servers and killed queries
> which had run for too long. In the past we had a programm for that, but
> somewhen it stoped working and nobody fixed it AFAIK.
>
> Because watching the mytop is a boring thing and I have to sleep too, I used
> the last 2-3 days to write a substitute of the old query-kiler. This program
> is working now. It does more or less the same as I did, but it send you an
> eMail when it killed one of your query. I think that is an improvment and I
> can spend my time with other things.
>
> You can find the parameters of when and if the killer works at [1]. Of corse
> there is always the possiblity of adjustments. Feel free to open bugs at JIRA
> or discuss on teh mailinglist.
So the max run-time is dependent on replag. But, considering this:
Replag s3 6050h 10m 44s
I currently get bombarded with killed-query-mails :-(
Magnus
_______________________________________________
Toolserver-l mailing list (Toolserver-l(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list:
https://wiki.toolserver.org/view/Mailing_list_etiquette
Hello all,
the last days when the replag on s3 was high, I looked for long-running-querys
from time to time. I noticed, that many queries which are run from inside of
webtools (like editcounters) had no LIMIT (see [1]). This is bad – no user
waits 5000s or more for a result and he/she is long go when the query still
needs resources (and at the end the result is abject). So please use a LIMIT
for your querys – even if they are fast for normal (the LIMIT doesn't hurt
then).
Please don't confuse this with the SQL-command LIMIT (which you should also
use if possibe ;-)).
Sincerly,
DaB.
[1] https://wiki.toolserver.org/view/Database_access#Query_time_limits
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
* http://status.toolserver.org/ is broken
* ts-major-outage(a)tcx.org.uk doesn't work
* s3/s6/s7 are lagged and overloaded
Are there any updates on these issues?
MZMcBride