Where do I find the current details?
https://wikitech.leuksman.com/view/All_servers has no primary image server.
https://wikitech.leuksman.com/view/Khaldun is only the backup server, and
is missing software versions.
Search found no NFS mount instructions other than:
mount 10.0.0.4:/home /home
zwinger:/home /home nfs bg,soft,rsize=8192,wsize=8192,timeo=14,intr,nfsvers=3 0
Neither of which seem to be related.
-------- Original Message --------
Knowing the specific version of the clients and server, and knowing the
mount options on the clients, will help us give a reasonable answer.
From the description, though, it sounds like switching to NFS over TCP
would help.
Time to time, I'm sure we've all noticed that wikipedia slows to a crawl.
Such as last night (local time), for about 15-20 minutes, reading was poor,
writing was nearly impossible, see:
April 20, 2006, 10:36 pm http://www.thewritingpot.com/wikistatus/
I tried looking at the site from various views. What struck me was that
no matter where I looked from here in the US, east or west or central, all
traffic seems to go to Florida, even when the servers are not responding.
No failover to other clusters?
Also, the DNS stopped serving inverse addresses. Compare:
9 ae-23-54.car3.tampa1.level3.net (4.68.104.107) 222.648 ms
ae-13-55.car3.tampa1.level3.net (4.68.104.139) 221.783 ms
ae-13-53.car3.tampa1.level3.net (4.68.104.75) 223.539 ms
10 level3-co1.tpax.as30217.net (4.71.0.10) 224.125 ms 222.308 ms 223.698 ms
11 e1-1.dr1.tpax.as30217.net (84.40.24.22) 230.567 ms 222.853 ms 227.562 ms
12 gi0-50.csw1-pmtpa.wikimedia.org (64.156.25.242) 222.394 ms 223.082 ms 223.56 ms
13 rr-206.pmtpa.wikimedia.org (207.142.131.206) 225.189 ms 215.542 ms 224.085 ms
11 ae-23-54.car3.Tampa1.Level3.net (4.68.104.107) 51.362 ms
ae-13-51.car3.Tampa1.Level3.net (4.68.104.11) 51.299 ms
ae-13-53.car3.Tampa1.Level3.net (4.68.104.75) 51.291 ms
12 level3-co1.tpax.as30217.net (4.71.0.10) 54.396 ms 53.682 ms 53.826 ms
13 84.40.24.22 (84.40.24.22) 54.127 ms 53.686 ms 53.826 ms
14 gi0-50.csw1-pmtpa.wikimedia.org (64.156.25.242) 59.873 ms 58.579 ms 55.517 ms
15 rr-235.pmtpa.wikimedia.org (207.142.131.235) 53.879 ms 54.104 ms 53.891 ms
That 84.40.24.22 inverse is only at 2 DNServers both located on the same
subnet (very bad practice):
;; ANSWER SECTION:
22.24.40.84.in-addr.arpa. 200 IN PTR e1-1.dr1.tpax.as30217.net.
;; AUTHORITY SECTION:
24.40.84.in-addr.arpa. 200 IN NS rns1.powermedium.com.
24.40.84.in-addr.arpa. 200 IN NS rns2.powermedium.com.
;; ADDITIONAL SECTION:
rns1.powermedium.com. 14128 IN A 84.40.24.94
rns2.powermedium.com. 14128 IN A 84.40.24.98
However, that loss of DNS responses from the same subnet leads to the
conclusion the subnet might be under congestive collapse. That is, this
lag might not be produced by wikimedia itself, but a problem with the
link to or within the facility.
Is there any other data that might correspond?
Does anybody have clues or notes on what actually might have been
happening at the time? RTG/MRTG?
- - -
Also, I'm seeing incorrect DNS configuration (CNAME to CNAME):
;; ANSWER SECTION:
en.wikipedia.org. 92 IN CNAME rr.wikimedia.org.
rr.wikimedia.org. 600 IN CNAME rr.pmtpa.wikimedia.org.
;; AUTHORITY SECTION:
wikimedia.org. 7200 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2006041914 43200 7200 1209600 3600
An automated run of parserTests.php showed the following failures:
Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Magic Word: {{NUMBEROFFILES}}... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Passed 300 of 303 tests (99.01%) FAILED!
Hi all!
I'm seeking a way to get rid of those huge URLs for pages with
non-latin symbols in their titles (in my case it's Russian). I found
an unresolved request #1450 in mediazilla on this theme, it contains
a comment with quite interesting advice (to use page id for it, like
/index.php?title=-&curid=1367).
Are there any more contemporary solutions to this issue? Ideally I'd
like to have a separate field for URL when creating/editing a page -
is it possible to create a plugin that would allow this? Another
solution would be having this field noneditable and automatically
filled with transliterated name of the page..
Thanks in advance,
Artem.
In the last two weeks it has happened several times that I lost
the tail of a long wiki page. I think the page gets truncated
when I'm doing a preview. Can it be that some chunked transfer
doesn't get completed? It has happened both on sites running
MediaWiki and on other wiki websites, so it seems to be browser
related rather than server related. Perhaps this is related to
Firefox 1.5 or 1.5.0.2? I run Linux. I never had this problem
with Mozilla 1.7.8. Any clues?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
An automated run of parserTests.php showed the following failures:
Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Magic Word: {{NUMBEROFFILES}}... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Passed 300 of 303 tests (99.01%) FAILED!
Hi,
after wandering through the archive of those lists, it seems that
nobody has yet mentioned that Wikimedia was accepted as a mentoring
organisation for the Google Summer of Code 2006.
http://code.google.com/soc/wikim/about.html
Students may apply for this in the first 8 days of May.
Please have a look at
http://meta.wikimedia.org/wiki/Summer_of_Code_2006 for suggestions
regarding possible projects.
It would be a great opportunity for us, yadda yadda etc. please apply.
Mathias
Tim Starling wrote:
>Ah, well in that case, I can tell you exactly what happened. The hero of the
>day was Zsinj, a canny newbie who had his eye on the relevant monitoring
>graphs, and alerted us to the problem immediately, using very specific
>terms, allowing us to track down and fix it rapidly.
I've got the "pretty graph" bug as described by Rob Church that he
states Mark and Domas also have. What can I say? I figure every little
bit helps and when all of the other IRC channels start filling up with
people wondering what's going on. I enjoy using my knowledge, although
limited, to help in any way possible.
It just so happened I was at the right place at the right time. While
there were other people noticing slowness and trickling into
#wikimedia-tech, I imagine it would have been longer delay in
resolving the issue had someone like me not been there. *shrug*
FYI: I'm EDT -4
William Bumgarner
aka Zsinj
I've run a quick simulation of the first-pass automatic conflict resolution for
the future single login migration:
Total registered usernames: 2,097,231
No edits on any wiki: 1,475,146 (70.3%)
Only registered on one wiki: 1,918,547 (91.5%)
Automatically resolved: 139,466 (6.6%)
Potential conflicts: 39,218 (1.9%)
Accounts can be automatically resolved ahead of time where all of the instances
of a name either have the same e-mail address listed (in which case the owner
could reset the password to the master account's) or have no listed
contributions (in which case we consider them fair game for reclaiming).
Potential conflicts are where one or more accounts exist for a name which have
some contributions listed, but the e-mail address doesn't match that of the
primary account. Many of these will be in fact owned by the same user, but just
didn't get the mail setting filled out.
Due to the salting of passwords, we can't currently perform an offline check for
matching passwords; however when the user first logs in after migration, the
passwords can be checked and any matching accounts can be automatically resolved
at that time.
In remaining cases where the passwords don't match, users will have to manually
select merging (if it's their account) or renaming (if it's someone else's) to
clear all conflicts.
Most such conflicts should be resolvable without too much administrator
intervention, at least in theory.
I'm running another pass to gather more statistics on how many potentially
conflicting accounts are barely-used versus often-used, will report in the morning.
(I've put some notes and the demo code I'm using for building these stats in the
CentralAuth project dir in SVN.)
-- brion vibber (brion @ pobox.com)
Just FYI, everybody. Being nice to friends and strangers alike is cool! Let's
all try to practice it a little more.
Assume good faith et al...
-- brion vibber (brion @ pobox.com)