So, is anyone else seeing really horrible mysql performance on s1? I heard a mysql upgrade introduced regressions, but I'm seeing queries take 2x - 3x as long, sometimes worse.
- Jason
Hello all,
some time pasted since our last maintaince-window in June, so hereby I
announce the next maintaince-window for
Wednesday, 9. November between 16:00 and 20:59 UTC.
During this time some software will be updated, server will get rebooted and
services may be broken or away. The biggest change will be that we move back
from ZEUS to apache – a test-enviroment is setup at the moment and will be
ready at 2. November at lastest (I will announce details in a later eMail).
If you have suggestions for software that should be updated (like php, perl,
mono or something), please fill in a JIRA-bug [1] and tag/label it with
"maintaince-window" until 2. November. The roots will list what will be
updated/changed/removed at [2].
Sincerly,
DaB.
[1] https://jira.toolserver.org/browse/TS
[2] https://wiki.toolserver.org/view/Admin:Next_Maintaince
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Hallo,
I'm working with the very huge mysql table 'revision' in the database
e.g. enwiki_p and would like to choose keys by hand using 'USE
INDEX(...)', because I think, mysql's choices are sometimes not ideal.
My difficulty is that if I try to do so, mysql claims that the key
__doesn't exist__ although it is displayed when I use 'EXPLAIN' and it
exists according to the database scheme.
Is there something special about the mysql implementation on the toolserver?
Thanks for any hints.
Philipp
NOW THE DETAILS:
To display that 'rev_timestamp' is in fact a key in the table
'revision', we can do this:
mysql> EXPLAIN SELECT rev_timestamp FROM revision LIMIT 10;
+----+-------------+----------+-------+---------------+---------------+---------+------+-----------+-------------+
| id | select_type | table | type | possible_keys | key
| key_len | ref | rows | Extra |
+----+-------------+----------+-------+---------------+---------------+---------+------+-----------+-------------+
| 1 | SIMPLE | revision | index | NULL | rev_timestamp
| 16 | NULL | 438608433 | Using index |
+----+-------------+----------+-------+---------------+---------------+---------+------+-----------+-------------+
1 row in set (0.00 sec)
Also from this website
http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/maintenance/tables.…
one can conclude that the index 'rev_timestamp' is there.
However:
If I try to set the key by hand, mysql claims the key would not exist
(also if I omit the quote signs):
mysql> SELECT rev_timestamp FROM revision USE INDEX(`rev_timestamp`) LIMIT 10;
ERROR 1176 (42000): Key 'rev_timestamp' doesn't exist in table 'revision'
Also in the description of the table there appear no keys:
mysql> DESCRIBE revision;
+----------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+---------------------+------+-----+---------+-------+
| rev_id | int(8) unsigned | NO | | 0 | |
| rev_page | int(8) unsigned | NO | | 0 | |
| rev_text_id | int(8) unsigned | NO | | 0 | |
| rev_comment | varbinary(255) | YES | | NULL | |
| rev_user | int(5) unsigned | NO | | 0 | |
| rev_user_text | varbinary(255) | NO | | | |
| rev_timestamp | varbinary(14) | NO | | | |
| rev_minor_edit | tinyint(1) unsigned | NO | | 0 | |
| rev_deleted | tinyint(1) unsigned | NO | | 0 | |
| rev_len | int(8) unsigned | YES | | NULL | |
| rev_parent_id | int(8) unsigned | YES | | NULL | |
+----------------+---------------------+------+-----+---------+-------+
11 rows in set (0.00 sec)
Hello all,
how Daniel Kinzler told you in his mail of 5. October already, the german
chapter hired an new admin for the toolserver. Her nick-name is nosy and she
is from Germany.
She will be in IRC on this Thursday after 19 o'clock UTC for a virtual meet-
and-greet-thing and some questions. I hope you all will give her a warm
welcome and be nice to her (I will be arround too).
Sincerly,
DaB.
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Hello all,
I am visiting the german OTRS-meeting this weekend and so I will me away from
friday midday until monday midday. I will try to check my mails from time to
time and (if possible) I will also join in the IRC every now and then, but
most time I will be away. I will also not grant new accounts on sunday as
usual – I will do this on monday or thuesday.
If something realy urgend happens, try to reach Duesentrieb or Nosy in IRC,
otherwise fill in a JIRA-Ticket.
Sincerly,
DaB.
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
I am getting a lot of emails about the following query taking too long
and being killed on thyme:
SELECT ns_id, ns_name FROM toolserver.namespacename where (ns_type
= 'canonical' or ns_type = 'primary') and dbname = 'enwiki_p'
Some of these emails claim that query ran over 3000 seconds. This
particular query should be quite fast. Is something up with the db
server?
- Carl
Hi all !
I've noticed that I cannot edit my crontab anymore… Indeed, if I type "cronie -e", I get the following error : « /tmp/crontab.XXXX6DaGnD: No space left on device. »
Then I reminded the mail that Daniel Kinzler sent to the mailing list a few days ago ("Toolserver status, and what WMDE is doing about it"). He explained that, unfortunately, the TS was « running out of disk space now ».
Moreover, I keep getting mail errors, with the same error report : « Unable to run job: job rejected: no script in your request. Exiting. »
Are both these problems linked to a lack of disk space ? If so, maybe every user might try to clear his home, in the aim to free some memory ?
Or maybe is there something that I misunderstood ?
Regards,
— Toto Azéro
Hi all,
If you write, maintain or are otherwise active in development, and directly
or indirectly make use of MediaWiki, then you should subscribe to:
mediawiki-api-announce(a)lists.wikimedia.org
That is a mailing list that only brings important announcements for
developers that use MediaWiki as an API.
Note that this list is not limited to API as "api.php" but about MediaWiki as
a application programming interface (API) in general.
Subjects that have announcements on that list:
* Important changes in database schema (columns or tables added, removed or
changed in such a way that you should change your queries. Think for example
of the addition of rev_deleted, queries should most likely query for
rev_deleted=0 now).
* Changes in the JavaScript API (methods being deprecated or removed in the
mediawiki.js library etc. as well as upgrades of third-party libraries that
ship with MediaWiki, such as jQuery).
* Major changes to the HTML layout (such as the change for the sidebar id to
#mw-panel)
* Hooks in MediaWiki PHP. Mostly for extension developers. Changes or
deprecation of hooks.
* And last but not least, the api.php itself. All major changes.
===
Although time will learn how the list is used, to readers and writers of this
list:
"All subjects should clearly indicate what needs changing and when!"
For example "Vector skin sidebar html ID changes to '#mw-panel' in 1.17".
Also, whenever Wikimedia has scheduled a deployment of revision(s) or entire
branches that expose any change that was previously announced, a new mail
should be sent here to remind/summarize upcoming changes (since gadgets
should/can't be changed until the new version is deployed but new versions can
be prepared or tested in advance)
Hope to see you soon on mediawiki-api-announce(a)lists.wikimedia.org :)
Please reply-to to wikitech to keep discussions about this central.
--
Krinkle
(sorry for the repost, the original mail got the wrong subject line by mistake)
Dear Toolserver Users
As you have probably notices, things havn't been going to well with the
toolserver lately. The main reason is that River is no longer available as much
as before, and we do not have a replacement. DaB is doing what he can, but far
too often, there's simply no one to fix things when they break. Also, our plans
to buy more storage went on hold because of this situation, and so we are
running out of disk space now. Which causes more things to break.
So, what is Wikimedia Germany doing about this? Here is what:
* Sebastian Sooth has taken charge of IT management at WMDE. He's way better at
this stuff than me, so that will help.
* We are hiring an interim admin. I hope we'll have the contract finalized by
next week.
* We will buy and install more storage. The new admin will plan that in
coordination with DaB, Sebastian and me. Expect this to take at least 8 weeks
before we have everything installed.
* Meanwhile, we'll try to assess and fix any other issues that have piled up
over the last couple of months.
* In the process, we'll create and improve documentation of the cluster, so it
becomes easier for people with access but little knowledge (like myself) to fix
things when they break.
* We will run a proper job offer for a payed toolserver admin. The idea is to
eventually have two payed (part time) system admins. The job offer will be
posted to toolserver-l.
I know things havn't been for the best lately, but I believe we are getting a
grip on the problem now. If you have any questions, please contact me.
Regards,
Daniel Kinzler
Wikimedia Deutschland e.V.
_______________________________________________
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