Rebuilding s2/s5 Databases starting tomorrow
--------------------------------------------
Key: MNT-1132
URL: https://jira.toolserver.org/browse/MNT-1132
Project: Maintenance
Issue Type: Emergency work
Security Level: Public (all users) (Any user can view this issue (default))
Components: daphne
Reporter: Marlen Caemmerer
The s2/s5 database host daphne runs out of disk space quite soon.
We have huge ibdata files there so we will rebuild them. After that there should be an incredible amount of free disk space.
The process of rebuilding the files will probably take a lot of hours so
the maintenance window would be starting tomorrow (Friday) 11 PM UTC and ending on Sunday 11 PM UTC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
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
Seems the daemon of cronie is not running in willow nor nightshade.
Listing the processes with cron name, there's only /usr/sbin/cron which
seems to be the daemon for sun crontab.
>From clematis process list (where cronie does continue running, so jobs
sent from submit were probably not affected), it seems the daemon which
should be running is /opt/ts/sbin/crond.
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(a)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…
>
Once again, a question on query killer. Below its report informs that
with near-zero replag a very simple count(*) only query on s6 takes
too long, and the killer expects SLOW_OK would help.
I think something is wrong fundamentally once such a query takes that
long, and there is no reason to add SLOW_OK and wait even longer.
mashiah
---------- Forwarded message ----------
From: <no-reply(a)toolserver.org>
Date: Sat, Nov 5, 2011 at 1:28 AM
Subject: [TS] Killed SQL-Task 15233729 on db-server z-dat-s6-a
To: mashiah(a)toolserver.org
Hello mashiah,
a MySQL-query of yours was killed because you didn't mark it as
SLOW_OK and it have run for 853 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 33s.
Sincerly,
Query-Killer.
This eMail was sent automaticaly, please don't reply.
SELECT count(*) INTO @tl_count FROM ruwiki_p.templatelinks
[1] https://wiki.toolserver.org/view/Database_access#Slow_queries_and_the_query…
Hello all,
few days ago I changed a script of SGE [1] to solve some problems. The munin-
graphs looks much better now, but of course they don't show everything, so
hereby I ask you: Has anyone had problems with SGE in the last 3 days? That's
include cronsub.
BTW: If you run a bot, try to move it into SGE; nightshade is quite busy from
time to time already.
Sincerly,
DaB.
[1] https://wiki.toolserver.org/view/Job_scheduling
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Does anyone know of a tool that shows "Combined contributions" of a bunch
of users (similar to how a warchlist/RecentChangesLinked shows the
'combined history' of a bunch of pages)
If the tool doesn't exist, could someone please see if it can be coded? We
need it to monitor the edits of all students in the [[WP:IEP]]. It should
take a page with a bunch of username links as an input and display a
watchlist-like output.
I'd write it myself, but I'm quite busy at the moment.
Thanks,
Manish*Earth* <http://en.wikipedia.org/wiki/User:Manishearth>*Talk* •
Stalk<http://en.wikipedia.org/wiki/Special:Contributions/Manishearth>