Hi!
As far as I know all Wikimedia Wikis use MySQL 4.0.40, since 2003.
That is rather old, it is not planned upgrading to a newer version? I
know it would not be easy, but the servers cannot run this version
forever.
Farewell,
Glanthor
Hi Folks:
I am a newbie so I apologize if I am asking basic questions. How would I go about hosting wiktionary allowing search queries via the web using opensearch. I am having trouble fining info on how to set this up. Any assistance is greatly appreciated.
DESEO CANCELAR MI SUBSCRIPCIÓN A WIKIMEDIA......
GRACIAS POR TODO. HARTLEY.
---------------------------------------
Red Telematica de Salud - Cuba
CNICM - Infomed
Hello,
probably it is worth telling why we had this headless chicken run
lately with all these new servers, and why we didn't do this slowly
but surely before all the slowdowns hit us.
We use Ganglia to understand cluster capacity, and the major overview
place is at:
http://ganglia.wikimedia.org/pmtpa/?gw=fwd&gs=Wikimedia%40http%3A%2F%2Fgang…
One of things that distorted our understanding was that aggregate
graph didn't exclude servers that were out of rotation for one reason
or another, so besides highly-loaded servers in the average
calculations, we had 0 load in the mix - thus showing quite some white
space in the aggregate. Fixing that immediately showed somewhat worse
situation than it used to look before (though looking at per-host
statistics already showed the problem).
Other issue is that any long-term graph (say monthly or yearly) shows
averages that do not represent peak time load properly.
So we do see average increase, but it does not look _that_ frightening.
Then... we had _sharp_ CPU usage increase three weeks ago. That still
needs investigation - but this could be anything, from some evil
metatemplate introduced on major wiki (maybe {{cite}} stuff
changed? :) to some bot that is hitting slower code paths to simply
bad code.
So, from operations perspective, it would be really nice to have:
a) A long-term data collection of maximum CPU load values (uhm, say,
maximum hourly averages).
b) Graphing / longterm data collection for profiling points
c) Ability to profile template costs/impacts apart from general Parser
profiling.
d) Alarm when we hit something above threshold. We have to notice that
within hour, not within days. :)
Or of course, being more attentive helps too.
Cheers,
--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
Just a quick update -- we're putting some new application servers online
which is helping with the CPU wall we've been starting to hit at peak
times recently:
http://leuksman.com/log/2009/02/12/your-donations-at-work-new-servers-for-w…
Thanks to everybody who donated to Wikimedia in the fundraiser!
-- brion
Hello!
You are receiving this email because your project has been selected to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we
hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relationship between the
PHP Team and the major projects.
If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.
The second and final release candidate of PHP 5.2.9 was just released
and can be downloaded from http://downloads.php.net/ilia/. Please try
this release candidate against your code and let us know if any
regressions should you find any. The goal is to have 5.2.9 out within
one week's time, so timely testing would be extremely helpful. Windows
binaries are also available and can be found here: http://windows.php.net/qa/
In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.
Best Regards,
Ilia Alshanetsky
5.2 Release Master
As I understand it, there is rightfully little interest in the
developer community to write a new parser function for every single
template need to come along.
Therefore, when it comes to a template like {{val}}, which now
generates rounding errors about 5–10% of the time because of the math-
based parser functions it must use, it would be nice if the template-
authoring community could have a character-counting parser function
that is not only suitable for {{val}}, but which could be a general -
purpose parser function that could be used for a great variety of
purposes.
A description of what {{val}} tries to do at its fundamental level is
described here:
http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style_(dates_and_numb…
Is there a developer whom I can have the author of {{val}} e-mail to
see if you two can arrive at a relatively easy-to-make parser function
that A) meets the basic needs of {{val}}, and B) has sufficient
utility to be useful for other character-counting needs?
It appears that the precision setting for PHP may be set
inconsistently across the WMF server pool.
PHP's internal floating point format is the same as a C double giving
~15 digits of precision. By default, current versions of PHP display
14 digits when rendering numbers for output. This is controlled by a
"precision" setting in php.ini that defaults to 14.
Operations like {{#expr:1.11111111111222}} on Wikipedia usually
displays 14 digits, but every so often the parser will uniformly
truncate all calls to #expr: to only 12 digits (i.e. for the example
given, you get "1.11111111111" without the "22" at the end). The
easiest way to understand this would be if a few of the servers have
"precision=12" set in php.ini.
By performing tests like: {{#expr:1.11111111111222-1.11111111111}} it
appears that in all cases the server is aware of those extra digits
and able to perform operations involving them, but it simply chooses
not to display them if it leads to too high a displayed precision.
The fact that the servers all seem to operate on the digits correctly
would suggest that this is a variation in software rather than some
more fundamental variation in hardware, and supports my theory that
this is caused by inconsistent configuration settings.
Would someone be willing to check whether some of the servers are set
to precision=12 and others to precision=14? I'm not sure if it is
useful, but I made a point of capturing the "Served by" comment a
couple times when I saw truncation to 12 digits. This included srv112
and srv176.
If there is variation in this PHP setting across the servers, then I
think one or the other setting should be adopted universally unless
there is some good reason not to. Since getting 14 digits seems to
happen most of the time right now, that would seem to be the natural
choice.
-Robert Rohde
Hello!
You are receiving this email because your project has been selected to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we
hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relationship between the
PHP Team and the major projects.
If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.
The first release candidate of PHP 5.2.9 was just released and can be
downloaded from http://downloads.php.net/ilia/. Please try this
release candidate against your code and let us know if any regressions
should you find any. The goal is to have 5.2.9 out within two to three
weeks time, so timely testing would be extremely helpful.
In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.
Best Regards,
Ilia Alshanetsky
5.2 Release Master