负载

　　春节前忙着把一些网站从自己独立托管的服务器搬迁到阿里云的平台中去，以前自己的服务器都是购买的顶配硬件（几年前就是16核、64G内存、8块硬盘），安装Linux+Apache+MySQL+PHP在同一台机器上，现在用了云服务器ECS做Web服务器，用云数据库RDS做MySQL服务，应该来说更合理，不过实际运行中也遇到问题。

　　先搬迁了几个小的网站，数据量不大、访问量不大，所以搬迁过去没有什么大的负载，ECS/RDS以及带宽什么都很富裕。但在搬迁一个数据量偏大、访问量也较大的网站时遇到问题，RDS的CPU总是100%，不运行自动检测超时MySQL进程并自动杀死该进程的脚本就完全不行，运行后算是可以维持，但一部分页面超时报错。

　　我查看了一下，主要是MediaWiki的包含动态页面列表DPL扩展的页面报错，怀疑是RDS配置选的过低，数次升级硬件配置、费用也在不断升高，从260M到600M、1200M、2400M都还是不行，后来不知道怎么碰巧就好了，此后负载一直非常低、用高配置RDS明显有很大浪费，于是我又申请了一个新的RDS，准备迁移数据后退掉老的高配RDS，但在新的RDS上遇到同样的问题，从260M升级到600M、1200M后问题依然存在，我知道再升级也没用，还是有其它问题。

　　在我们一些用Drupal搭建的大数据量网站中，Boost模块产生的缓存文件数量非常多，以至于运行cron期间无法更新完毕，我们后来就采用了不自动更新缓存文件，而是人工根据需要在服务器上直接删除缓存文件的办法。

　　但当缓存文件数量达到数十、上百万的时候，需要很长时间删除，在这个过程中如果还有用户访问、产生新的缓存文件，将导致硬盘占用达到100%，长期这样的话，可能让服务器硬盘不堪重负、服务器出现负载上升、网站无法访问的情况。

　　这个问题一直困扰了我们好长时间，以前都是采取人工每次删除少量文件，逐步试着来进行，这导致要花费好些时间精力。昨天在网上查找了一些资料，然后改动了一下，做了一个批处理：

#!/bin/bash

for name in `find /mnt/gb3/will-delete -name "*" -print`
do
    echo $name
    rm -f $name
    sleep 0.01
done

　　根据实际情况修改其中的路径、名称、延时，把这个命名为slowremove.sh，运行就可以了。

　　从7月初到10月底的4个月时间中，我们已经在服务器上导入了大量数据，建成了一批新的子网站，在接下来的一段时间内我们不准备继续大增数据量了，而是对已经导入数据的网站进行精细优化调整，这个月已经开始了这方面的工作。

　　MediaWiki平台的网站都是去年以及以前建成的，这次基本没有大的调整，只是一部分网站对模板进行了更新，以便嵌入microdata微数据标记，虽然也需要运行后台更新、重新生成缓存文件，不过这个对服务器的负载影响不算很大，是可以承受的。

　　而在对今年新做的Drupal平台的改进中，如果只是修改内页模板、block以及menu等的话，对负载的影响也不算很大，但如果涉及到新建Views就可能对MySQL造成压力，特别是我们近几个月添加的都是大数据量的子网站，一个站点就可能有数百万计的页面，用Views生成索引列表的时候运算时间很长，而当有大量这样的运算同时进行的时候，服务器就会不堪重负。

　　我和同事在前面商量网站改版的时候，没有过多考虑负载情况，只是本着浏览者方便的角度出发，计划增加多种Views索引列表来替代以前的Taxomony分类，还要增加地域分级的索引以及地域和行业的交叉索引，这些在设计Views中就知道将会是mysql load killer。

　　在以前的MediaWiki所建站点中，我们启用了外部的Squid缓存和MediaWiki本身的File Cache两种页面缓存方式。

　　File Cache设置成时间无限长，只有页面或者包含的模板变化时才会更新，这项设置对缓解服务器压力起到了关键作用，如果不启用的话，网站很快就会变得无法访问。缓存的更新问题也基本上还好，在正常控制下工作。

　　MediaWiki软件默认的Squid缓存时间是5个小时，我们早就改成了24小时，不过考虑到我们很多网站的页面其实变化率很低，多数几个月都不会变动，其实是可以设置成更长的。我最近进行了设置修改，将Squid缓存的最长时间从1天改为了10天。如果是页面有变化，应该也会马上通过purge命令来让Squid更新的，不会造成延误影响。