“MediaWiki文件缓存的弊端”的版本间的差异
(新页面: {{日志顶部}} --~~~~ 启用MediaWiki的文件缓存(File Cache)功能,并且把过期时间改为永不过期后,服务器的负载确实大大降低了,因为老的...) |
|||
第6行: | 第6行: | ||
也因为启用了文件缓存后效果不错,我把[[Telecode:|查号吧]]网站中的手机号段、小灵通/一号通号段页面中去掉的一万个号码列表再次恢复了,不过在生成新的文件缓存页面时遇到问题,因为每个缓存文件大约有170K大,是普通页面的10倍左右,所以生成一个文件所用的时间也要几十秒,而同时访问(例如搜索引擎爬虫一起来快速爬)的时候,就造成很多页面报错,而MediaWiki的File Cache功能不加区分地把这些报错页面进行了缓存,而且以后不会自动更新。 | 也因为启用了文件缓存后效果不错,我把[[Telecode:|查号吧]]网站中的手机号段、小灵通/一号通号段页面中去掉的一万个号码列表再次恢复了,不过在生成新的文件缓存页面时遇到问题,因为每个缓存文件大约有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”或者“数据库错误 发生数据库查询语法错误。 | |
+ | 可能是由于软件自身的错误所引起。 | ||
+ | 最后一次数据库查询指令是: | ||
+ | <blockquote><tt>(SQL查询已隐藏)</tt></blockquote> | ||
+ | 来自于函数 "<tt>MediaWikiBagOStuff::_doinsert</tt>"。 | ||
+ | MySQL返回错误 "<tt>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定期更新,所以即使有一些报错页面,也会在定期更新时纠正,现在改为永不更新(除非页面发生变化)后负载是下降了但如果有错误缓存就不能得到纠正,只有以后把脚本做成定时自动执行,来发现错误并删除。 | 以前因为保持File Cache定期更新,所以即使有一些报错页面,也会在定期更新时纠正,现在改为永不更新(除非页面发生变化)后负载是下降了但如果有错误缓存就不能得到纠正,只有以后把脚本做成定时自动执行,来发现错误并删除。 | ||
第14行: | 第22行: | ||
另外,这个月等MediaWiki 1.15正式颁布发布后,准备把一直用了两年的1.10进行升级,看看一些发现的MediaWiki系统问题是否得到了改进。 | 另外,这个月等MediaWiki 1.15正式颁布发布后,准备把一直用了两年的1.10进行升级,看看一些发现的MediaWiki系统问题是否得到了改进。 | ||
− | {{TAG|MediaWiki|缓存|File Cache}} | + | {{TAG|MediaWiki|缓存|File Cache|报错|脚本}} |
{{别名|MediaWiki的File Cache报错页面的发现及处理}} | {{别名|MediaWiki的File Cache报错页面的发现及处理}} | ||
{{日志底部}} | {{日志底部}} |
2009年10月15日 (四) 11:14的版本
--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系统问题是否得到了改进。
标签:MediaWiki、缓存、File Cache、报错、脚本。 |
相关内容:
|