I'm seeing the same problems -- Wikipedia is locked up most of the time, only responding occasionally at random, making it effectively unusable.
Netcraft reports that is is running Apache/1.3.23 (Unix) PHP/4.0.6 mod_fastcgi/2.2.12 on Linux.
There is now a severe Apache security vulnerability that affects
Apache 1.3 all versions including 1.3.24; Apache 2.0 all versions up to 2.0.36; Apache 1.2 all versions.
This looks like something that should be fixed ASAP. And it just might explain some of the problems seen.
-- Neil
On Sun, Jun 30, 2002 at 08:42:47AM +0100, Neil Harris wrote:
I'm seeing the same problems -- Wikipedia is locked up most of the time, only responding occasionally at random, making it effectively unusable.
Indeed. I still have the impression that it has to do with unsuccesful searches, but I may be mistaken. Does anybody know when Wikipedia's code was updated from CVS for the last time? Or has anybody taken a good look at the log-files to see what it is that is causing Wikipedia to grind practically to a halt? Are we really sure that it is greedy spiders?
Jimbo? Anybody?
-- Jan Hidders
On Sunday 30 June 2002 09:51, Jan.Hidders wrote:
On Sun, Jun 30, 2002 at 08:42:47AM +0100, Neil Harris wrote:
I'm seeing the same problems -- Wikipedia is locked up most of the time, only responding occasionally at random, making it effectively unusable.
Indeed. I still have the impression that it has to do with unsuccesful searches, but I may be mistaken. Does anybody know when Wikipedia's code was updated from CVS for the last time? Or has anybody taken a good look at the log-files to see what it is that is causing Wikipedia to grind practically to a halt? Are we really sure that it is greedy spiders?
I suspect it is searches for users' contributions. These always take a long time and almost always time out, even when browsing was fast just before I do one. It makes no difference how many contributions the user has made. Perhaps an index is missing and needs to be made.
phma
On Sun, Jun 30, 2002 at 10:26:19AM -0400, Pierre Abbat wrote:
I suspect it is searches for users' contributions. These always take a long time and almost always time out, even when browsing was fast just before I do one. It makes no difference how many contributions the user has made. Perhaps an index is missing and needs to be made.
Er, surely the developer who programmed that ...
Jimbo? Could you check if there is an index on 'old_user_text' in the table 'old' and on 'cur_user_text' in the table 'cur'? If not please tell MySQL the following:
ALTER TABLE old ADD INDEX ( old_user_text );
ALTER TABLE cur ADD INDEX ( cur_user_text );
-- Jan Hidders
cur_user_text and old_user_text are "tinyblob", so MySQL won't index them.
I'm not sure, however, if we should make big changes to the database anymore. The new source from Lee is pretty stable and has a more elaborate database structure. Try
http://www.piclab.com/wikitest/wiki.phtml?title=Special:Contributions&ta... =Magnus_Manske
for an example of the user contributions.
As we will switch to that codebase when we switch servers, there's probably no need to fix minor bugs here for the time being.
Magnus
-----Original Message----- From: wikipedia-l-admin@nupedia.com [mailto:wikipedia-l-admin@nupedia.com]On Behalf Of Jan.Hidders Sent: Sunday, June 30, 2002 5:28 PM To: wikipedia-l@nupedia.com Subject: Re: [Wikipedia-l] Wikipedia software; Apache vulnerability
On Sun, Jun 30, 2002 at 10:26:19AM -0400, Pierre Abbat wrote:
I suspect it is searches for users' contributions. These always take a long time and almost always time out, even when browsing was fast just before I do one. It makes no difference how many contributions the user has made. Perhaps an index is missing and needs to be made.
Er, surely the developer who programmed that ...
Jimbo? Could you check if there is an index on 'old_user_text' in the table 'old' and on 'cur_user_text' in the table 'cur'? If not please tell MySQL the following:
ALTER TABLE old ADD INDEX ( old_user_text );
ALTER TABLE cur ADD INDEX ( cur_user_text );
-- Jan Hidders
[Wikipedia-l] To manage your subscription to this list, please go here: http://www.nupedia.com/mailman/listinfo/wikipedia-l
On Sun, Jun 30, 2002 at 05:55:12PM +0200, Magnus Manske wrote:
cur_user_text and old_user_text are "tinyblob", so MySQL won't index them.
Hmm, any reason why you didn't make them binary varchar's? But are you sure our MySQL can't index those? The manual says that since version 3.23.2 you can index BLOB's if you are using MyISAM tables and we use those.
As we will switch to that codebase when we switch servers, there's probably no need to fix minor bugs here for the time being.
The query without an index looks really really expensive to me. If this is what makes Wikipedia unusable at the moment, I wouldn't call it a minor bug. Maybe we could simply turn it off for a short period and see what happens?
-- Jan Hidders
cur_user_text and old_user_text are "tinyblob", so MySQL won't
index them.
Hmm, any reason why you didn't make them binary varchar's? But are you sure our MySQL can't index those? The manual says that since version 3.23.2 you can index BLOB's if you are using MyISAM tables and we use those.
I tried your commands; didn't work because of the BLOB thing.
As we will switch to that codebase when we switch servers,
there's probably
no need to fix minor bugs here for the time being.
The query without an index looks really really expensive to me. If this is what makes Wikipedia unusable at the moment, I wouldn't call it a minor bug.
Any hard evidence to cover that theory?
Maybe we could simply turn it off for a short period and see what happens?
That's probably worth a shot; we could live without that function for a while, and there'd be no information loss if we turn it off. Jimbo? Jason?
On Sunday 30 June 2002 12:40, Magnus Manske wrote:
Maybe we could simply turn it off for a short period and see what happens?
That's probably worth a shot; we could live without that function for a while, and there'd be no information loss if we turn it off. Jimbo? Jason?
Well I use it to figure out if a file's junk: if the uploader hasn't contributed anything, it's junk. But it may be enough to put special:contributions in robots.txt. I suspect that the robots are reading those pages more than the people.
phma
wikipedia-l@lists.wikimedia.org