Hello,
While learning PHP I came across the following warning in the php manual
and remembered one frequent error message in wikipedia (maximum number of
database connections exceeded...):
There are a couple of additional caveats to keep in mind when using
persistent connections. One is that when using table locking on a
persistent connection, if the script for whatever reason cannot release
the lock, then subsequent scripts using the same connection will block
indefinitely and may require that you either restart the httpd server or
the database server. Another is that when using transactions, a
transaction block will also carry over to the next script which uses that
connection if script execution ends before the transaction block does. In
either case, you can use register_shutdown_function() to register a
simple cleanup function to unlock your tables or roll back your
transactions. Better yet, avoid the problem entirely by not using
persistent connections in scripts which use table locks or transactions
(you can still use them elsewhere).
Do we actually use persistent connections and is this problem affecting
wikipedia?
greetings,
elian
--
Sex is hereditary. If your parents never had it,
chances are you won't either.
Hi,
can we upgrade the hu.wikipedia.org to the new software? Zoltan Simon,
who has contacted wiki-en a few days ago and with whom I have been
corresponding since, has expressed interest in starting the Hungarian
Wikipedia (which is currently empty). I think it would make more sense
to upgrade the software before telling him how to work on it.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
A few days back someone suggested that we could switch the tables from
MyISAM to InnoDB to help avoid slowdowns where the whole system is
waiting on a table lock to be released, without having to rewrite as
much of our code as we would to change to a different dbms such as
postgres. But, the fulltext indexing we use to drive the search engine
only works on MyISAM tables.
However... with MySQL not all tables in a database have to be of the
same type. There are already separate columns for the fulltext index
thanks to the need to strip out markup; why not move them out to a
separate table, keyed to the cur_id, and make it MyISAM while the other
tables move to InnoDB?
It'd only be written to on page edit and deletion, and only read on
search and mispeelings, so there'd be less contention on it than there
is on the much-abused cur table. And for extra bonus points, the current
revisions download dump wouldn't be weighted down by the stripped copy
of every article's text.
We may have to recompile MySQL to enable InnoDB, but relatively little
of our code should have to change to take advantage of it.
-- brion vibber (brion @ pobox.com)
I just installed wikipedia on my webserver and can't for the life of me
figure out how to log in as an admin. I downloaded the latest version
from CVS.
Thanks,
Carl Youngblood
> Currently you must manually switch this on in your
> preferences, and you
> get both X edit and X display or neither; I haven't
> had a chance yet to
> hack in the big, friendly button at the top of the
> screen.
Yes, but the problem is that I think the majority of
users would like to edit in the x-system and view in
unicode. Currently, it is not possible to do this.
For example, in most internet cafes (where I do some
of my editing), I want to view the text in unicode,
but there's no way to type in unicode. In this old
system it did not matter if people typed in x-system
or unicode, it always works. Could we carry this
functionality over to the new software? I know
Unukorno also wants this functionality.
Chuck
=====
I'm in the Czech Republic!! Mi estas en Cxehxio!!
=========================================
Travel Plans: http://eo.wikipedia.org/wiki/Chuck_SMITH
My Webpage: http://amuzulo.babil.komputilo.com/
Enciklopedio: http://eo.wikipedia.org/
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de
Hello all,
Polish Wikipedia is testing the newly installed server and
we wonder if this is a bug :
[[m:Main Page]] works --> http://meta.wikipedia.org/wiki/Main_Page
and [[w:Lithium]] does not --> empty
Regards,
Kpjas.
I hacked up the fulltext search/index code a bit to work on UTF-8
despite MySQL's lack of direct support: a Language::stripForSearch()
function is called to do any necessary mangling of character sets before
we store the indexable version of the text.
For Esperanto, Polish, Russian, Czech and Korean I set it to just fold
the text to lowercase (so search is case insensitive) and then convert
all UTF-8 sequences into hex strings which MySQL won't mistreat.
For Chinese and Japanese, things are a bit more complicated, as there is
no word spacing in the original text but the fulltext search works on
words. For Chinese I just set it to put spaces around every character;
it needs a lot of tweaking, but it sort of works. If you search a single
character it works great, but multi-character sequences don't behave as
expected.
For Japanese, I have it divide up the text at boundaries around chunks
of the same type of character (hiragana, katakana, or kanji), which does
a pretty good first approximation of dividing at the right place. It
could probably use some more work as well. When searching a word/short
phrase that divides across character types (ie, 'furansugo' which mixes
katakana and kanji) results may not be as expected.
-- brion vibber (brion @ pobox.com)
As we discussed over the phone, my SELECT query should have had a LIMIT 99 clause on it.
I will put a LIMIT clause on all future queries, for safety's sake.
I don't want the shame of causing a 52-minute lag again!
Ed Poor
-----Original Message-----
From: Poor, Edmund W.
Sent: Friday, November 22, 2002 8:19 PM
To: 'Brion VIBBER'
Subject: Queries and the "lag" problem
Brion,
A few minutes ago, I submitted a SELECT query.
But, thinking it might be too long (since I had neglected to put "limit 99" on it) I tried to abort the query by hitting the Stop button on my browser.
Well, since then, wikipedia has been completely unresponsive. Which leads me to 2 thoughts:
* Bad Ed! Don't submit unbounded queries like that (I should be more careful)
but perhaps more generally,
* Could the slowness of the server feed on itself? If users hit stop or just close their page, does the server wait and wait for a long time trying to give them the page they just said they no longer want? And then does this long wait make others give up and leave, which only makes the server wait for them too?
Or maybe it's just a coincidence. I'd love to know what the logs show in this case tonight. It happened some time between 8:00 P.M. and 8:15 P.M., US East Coast time.
Ed Poor
I like the idea of moving the fulltext column to a separate table, keyed to the cur_id. That's the kind of normalization that can't hurt, and is likely to help.
Ed Poor
Could someone make Ed Poor an account, and transmit a password to him
in some secure fashion. PGP would be good, but if that's not possible,
a telephone call would be fine, too.
----- Forwarded message from "Poor, Edmund W" <Edmund.W.Poor(a)abc.com> -----
From: "Poor, Edmund W" <Edmund.W.Poor(a)abc.com>
Date: Fri, 22 Nov 2002 11:10:04 -0500
To: "Jimmy Wales" <jwales(a)bomis.com>
Subject:
I used to be a Network Administrator for a company with 300 seats, plus as a software developer I had admin rights to all the company's MS SQL Server databases. Unclogging the network and resolving database gridlock were 2 areas I excelled in there.
If you'd like to give me developer access, I could take a look around and try to see what keeps slowing us down. I guess it's a lot of different things, many of which Brion has already identified.
But the fact that restarting the machine always speeds thing up again indicates the probable presence of one or more as-yet unidentified problems.
Of course, as a "developer" I would be ever scrupulous about the "rules" -- I would absolutely not use developer rights to, say, win a POV battle or unilaterally ban an obnoxious user.
Ed Poor
"Opinions and proposals expressed in this letter are mine personally, and are unrelated to any aims or policies of my employer."
----- End forwarded message -----