你在这里


Cache

Drupal的MySQL过度膨胀,清理缓存、翻译表

James Qi 2012年10月16日 - 16:59 发布

  我们做的Drupal网站多是数据查询、展示类型的,当数据量大的时候,导入就需要很长时间,而随着站点的建立、访问,还会产生一些日志、缓存等数据,一些站点的MySQL数据库占用空间会越来越大,部分甚至都超过10G了,导致访问很慢、备份困难。

  虽然说Drupal的Cron可以做一些清理的工作,但实际上有些数据表还是清理不了,这几天我就人工删除了一些数据表,例如BoostCache相关的表、Cache相关的表。

  另外有些非英文站的locales_source表也极大,我打开这个表发现很多重复的、Views页面整个都成了翻译的source,而locales_target表中并没有对应的翻译文本。我就先把这些Views页面产生的数据项全部删除了 DELETE FROM locales_source WHERE location LIKE '%/postcode/%' OR location LIKE '%/area/%' ,不过随着再次访问,又会出现新的,还没有完全解决。


  2013年2月19日补充:*.chn.youbianku.com系列网站再次出现服务器负载高的情况,数据库中locales_source表达到数G至上十G,先还是采取上述办法删除,以后再想法彻底解决。

Drupal网站中不让Cron自动更新Boost Cache及XML Sitemap

James Qi 2011年12月12日 - 22:27 发布

  在一般的Drupal网站中,都是通过设置Cron定期运行来对Boost Cache、XML Sitemap进行更新,但我们在大数据量的Drupal网站中觉得需要进行一些改进。

  首先来说Boost Cache,对于数十万甚至上百万的数据量,如果都进行静态页面缓存的话,占用硬盘过大,小文件太多,可能效率还不如不要静态页面缓存,这样的时候我们一般关闭了详细内容页面的静态缓存,只对分类页(Taxonomy Terms)、索引页(Views)进行缓存,就是这样,静态缓存的文件数也有数万个以上。这时如果通过Cron来定期让静态缓存失效的话,可能会出现删除时间过长而报错的情况,而且这些缓存本身也很可能不需要进行周期性更新,因为这些数据基本上都是长期固定的。

  我现在的做法是将Boost中的设置Clear expired pages on cron runs:为“Disabled”,只有对网站进行过数据大量更新、模板更新等影响很大的操作时,才人工点击“Clear All Boost Cache”按钮来执行更新,而我在点击这个按钮后还可能碰到数据库报错的情况,这时磁盘上的静态文件可能没有被删除,还需要进入Linux服务器系统,用rm -rf /usr/local/apache2/htdocs/.../cache_path/*这样的命令来删除。

Drupal中更新某个单独页面Boost Cache的办法

James Qi 2011年11月9日 - 14:03 发布

  Drupal的Boost Cache是个好东西,可以实现将匿名用户访问的内容完全静态化缓存起来,绕过PHP和MySQL,只需要Apache就可以对付用户的浏览,可以极大提升网站性能。Boost模块的配置也比较灵活、复杂,可以设置排除某些种类的页面不缓存、可以设置更新周期及办法等等。今年我们用Drupal搭建的网站多数都是数据量大、更新不是很频繁的内容,基本上都使用了Boost。

  不过偶尔有网友发来邮件,要求我们删除或者更新某个页面内容,如果只是删除某个页面的话,包含这个页面信息的分类页、Views页面可能都因为有Boost缓存而无法自动清除。还有我们自己在调试、修改网站的时候也需要更新一部分页面缓存以便验证效果。

  以往解决的办法有两种:

自由标签:

修改Drupal网站的robots.txt来避免搜索引擎蜘蛛直接爬取cache路径的内容

James Qi 2011年10月31日 - 10:31 发布

  前些天收到Google Webmaster Tools的提醒邮件:

Googlebot 发现您的网站中包含大量的网址:http://jilin.youbianku.com/

October 24, 2011

Drupal首页对匿名用户报错的问题

James Qi 2011年7月19日 - 09:24 发布

  以前做的Drupal网站曾经出现过偶尔首页无法打开,报404错误的情况,不过出错几率不高,按月来计算的,例如31个省份的子网站,可能2个月左右出现一次其中一个网站的首页报错的情况。这个首页的问题只是对匿名用户报错,登录用户正常,怀疑与缓存设置有关。反复试验后,发现在菜单的Performance项中点击Clear core page cached data按钮后,首页可以恢复正常。

  近期推出的一批世界各国邮编子网站也遇到一些问题,与前面有些类似,但又不完全相同。现象是用监控软件定期扫描时,会出现偶然的、间断性的报错,监控软件提示是无法找到设定的关键字,而这时人工用浏览器访问基本上都是正常的。这个问题反反复复不断出现,各个子网站基本上都遇到,所以手机接到的报警不断,连续有1、2周也没有找到原因。出现报错的这个时候,在菜单的Performance项中点击Clear core page cached data按钮后,首页可以恢复正常,但可能过几个小时、几十个小时后问题再次出现。我又试过把block cache关闭、去掉最小的缓存时间周期等,都无法解决,最后只能关闭drupal本身的Anonymous page caching,只保留boost的Boost File Cache,才能不再出问题。

自由标签:

订阅 RSS - Cache