Last modified: 2013-09-16 17:43:38 UTC
Hello, For big wiki using objectcache instead of memcache, the update of mediawiki database finishes by a "Purging caches" which is very (hours for our 15k articles wiki) long and blocks all accesses to the database. I investigated and found that the wk_objectcache table is purged by deleting elements one by one with the DELETE command. If the DROP TABLE / CREATE TABLE was used, it would take less than a second, even for big wikis. Since all the data should be dropped from this table, I think this fix could help big wiki without memcache. Best regards, Vincent Lines I use: DROP TABLE IF EXISTS `wk_objectcache`; CREATE TABLE IF NOT EXISTS `wk_objectcache` ( `keyname` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '', `value` mediumblob, `exptime` datetime DEFAULT NULL, UNIQUE KEY `keyname` (`keyname`), KEY `exptime` (`exptime`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Thanks for taking the time to report this and investigating! (In reply to comment #0) > the update of mediawiki database Does this refer to a MediaWiki upgrade (from which version to which version?), or what are steps to reproduce your setup?
Yes it refers to a MediaWiki upgrade (from 1.20 to 1.21 for example but it has been like this for a while). The steps to reproduce is to make a big wiki using the object_cache, fill the object_cache by using the wiki, and then launch the php maintenance/update.php script (even current version). It will freeze at "Purging caches...".
This happened to me exactly while updating from 1.19.6 to 1.21.2. For reference, my objectcache table was about 350MB, as measured by the output of mysqldump.