MediaWiki的File Cache报错页面的发现及处理
“MediaWiki的File Cache报错页面的发现及处理”和“MediaWiki文件缓存的弊端”在这里有相同的下面内容。
--James Qi 2009年6月1日 (一) 11:57 (CST)启用MediaWiki的文件缓存（File Cache）功能，并且把过期时间改为永不过期后，服务器的负载确实大大降低了，因为老的页面只要访问一次后就保存成了静态HTML文件，以后都不需要访问数据库了，再加上前段还有一级Squid缓存，对于匿名用户访问来看，浏览速度提升效果很明显。
也因为启用了文件缓存后效果不错，我把查号吧网站中的手机号段、小灵通/一号通号段页面中去掉的一万个号码列表再次恢复了，不过在生成新的文件缓存页面时遇到问题，因为每个缓存文件大约有170K大，是普通页面的10倍左右，所以生成一个文件所用的时间也要几十秒，而同时访问（例如搜索引擎爬虫一起来快速爬）的时候，就造成很多页面报错，而MediaWiki的File Cache功能不加区分地把这些报错页面进行了缓存，而且以后不会自动更新。
上周手工检查一个网站的缓存目录，就发现很多小于1K的缓存文件，都是报错的页面（内容类似这样：“Fatal error: Maximum execution time of 30 seconds exceeded in /usr/local/apache2/htdocs/telecode/includes/Parser.php on line 2717”或者“数据库错误 发生数据库查询语法错误。 可能是由于软件自身的错误所引起。 最后一次数据库查询指令是:
(SQL查询已隐藏)
来自于函数 "MediaWikiBagOStuff::_doinsert"。 MySQL返回错误 "1205: Lock wait timeout exceeded; try restarting transaction (221.233.134.182)”），昨天让公司同事帮忙写了脚本批处理检查，几个服务器上都有几千个这样小于1K甚至大小为0的错误文件，加起来有上万个，手工更新起来不现实，就让同事批量删除了，以后有访问的时候应该可以重新生成。
另外还有一种出错的页面，出现了页面菜单、分类、底部内容，而中间的关键内容却是一个访问数据库的报错（内容类似这样：18dao has a problem Sorry! This site is experiencing technical difficulties. Try waiting a few minutes and reloading. (Can't contact the database server: Host '221.233.134.182' is not allowed to connect to this MySQL server (221.233.134.182))），这样的文件大小有15K左右，和正常的页面差不多或者稍微小点，这只有用关键词来搜索找到，同事小明的Linux脚本技术还不错，进行了一些设置、运行后，也都找出来了，比小于1K的那种报错页面少很多，但这些也都是需要重新生成的，只有批量删除了。
以前因为保持File Cache定期更新，所以即使有一些报错页面，也会在定期更新时纠正，现在改为永不更新（除非页面发生变化）后负载是下降了但如果有错误缓存就不能得到纠正，只有以后把脚本做成定时自动执行，来发现错误并删除。
另外，这个月等MediaWiki 1.15正式颁布发布后，准备把一直用了两年的1.10进行升级，看看一些发现的MediaWiki系统问题是否得到了改进。
补充几个删除文件缓存的命令：
# 删除超过5天的缓存文件：
find /path/to/cache -type f -mtime +5 -exec rm {} \;
# 删除包含“分类:”的.html.gz缓存文件：
find /path/to/cache -type f -name "%E5%88%86%E7%B1%BB%3A*.html.gz" -exec rm {} \;
# 删除包含“Category:”的.html缓存文件：
find /path/to/cache -type f -name "Category%3A*.html" -exec rm {} \;
--James Qi 2010年11月1日 (一) 20:20 (CST)
| 标签：MediaWiki、缓存、File Cache、报错、脚本。 |
相关内容：
|
别名：MediaWiki的File Cache报错页面的发现及处理。
