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、报错、脚本。 |
相关内容:
|