Topic on Talk:ResourceLoader/Flow

Hi, sorry if this is a wrong place to ask ... in our install of Mediawiki 1.19 (http://wiki.geogebra.org/en/Special:Version ) the ResourceLoader stores some Javascript which contains timestamps: [["site","1352754747",[],"site"],["noscript","1352754747",[],"noscript"],["startup","1352859900",[],"startup"],["user","1352754747",[],"user"],["user.groups","1352754747",[],"user"],["user.options","1352859900",[],"private"],["user.cssprefs","1352859900" ... in the cache (objectcache table in MySQL) with expiration date 2038. I guess such entries are never hit (as they contain timestamps, which are often unique for unregistered users) and since of the long expiration date they fill the cache -- in a couple of weeks it grew to 690MB. What's the best way to circumvent this problem?

Ouch, that's a problem. The cache keys in question probably contain the word 'minify' and an md5 hash, right? If so, it's the JS minifier cache, which caches the result of JS minification, and because the same original code always results in the same minified code, it's cached forever as it can never change.

I'm afraid that for now you'll have to periodically purge the objectcache table of keys with this pattern; I've filed a bug about it, and once it's fixed, there will be a patch that you can apply that addresses this behavior. But it may take up to a few months for this patch to get written, unfortunately. An alternative workaround is to use memcached instead of the DB cache; if you have enough users that you're producing >30MB/day in cache cruft, that might be a good idea anyway. memcached uses a fixed maximum size for its cache, and when the cache fills up, it will start throwing out (evicting) old entries, with the least recently used (LRU) entries getting evicted first. This is what we use on our production wikis (Wikipedia and sister sites) as well.

Thanks for the report, this is a quite nasty issue that we hadn't heard about before. We never experienced it ourselves because we use memcached, which is not affected by this problem as it automatically removes unused entries if the cache grows too large.

Thanks for the fast reply! Yes, the keys contain "minify". We will consider switching to memcached, but for now I've just hacked ResourceLoader.php -- instead of $cache->set( $key, $result); we now use $cache->set( $key, $result, time()+86400); I guess this hack would be a bad thing to do on a large wiki, but it should be OK for our medium sized one (~5k pageviews per day).

That should be fine, it'll expire the minifier cache after a day that way. Even on a large wiki, that would just be a minor annoyance, not a real problem. In fact, we might actually end up with something similar to that as a fix.

Hi Catrope, I was wondering what the bugId number was for this issue. We too have been having this issue (mw 1.18) on our corporate site where the objectcache table grows past a a few GB (at one point it was 28gb). After a while I just go in there and run TRUNCATE TABLE objectcache; to fix it up, however this is not the correct solution.

I recently checked the latest build, 1.20.4 to see if something like the suggested fix was placed in ResourceLoader.php, but did not see it. I was hoping to find the modify for $cache->set( $key, $result ); to something like, $cache->set( $key, $result, time()+86400);.

We love using MW here for our development and support personnel. This bug is our biggest show-stopper and want to upgrade to the latest version, but i want to make sure before I take our site down for maintenance.

Thank you! and keep up the good work

This post was posted by Dsuess~mediawikiwiki, but signed as Dsuess.

https://bugzilla.wikimedia.org/show_bug.cgi?id=42094 is the bug number.

(Sorry for the late response, I don't monitor this space very well.)