Drupal 8在上月推出，Drupal 6在3个月后不再提供支持，今年我们本来就花了很多时间在做服务器迁移到阿里云以及Drupal系统升级的事情，现在还剩下的几个Drupal 6系列网站的升级工作也要抓紧进行。
升级工作的流程我们已经很熟悉了，可以批量进行（见博客文章《用Drush批量升级Drupal 6到Drupal 7》），但遇到数据量很大的站点时，content migrating 的时间特别长，还容易因为服务器内存、php运行时间限制、SQL时间过长等原因报错失败，数量在几十万以内的升级起来都很快，但单个站点数据量达到数百万、每个站点的字段数量有几十个、系列网站有几十个子网站的时候，升级时需要的服务器资源和运行时间就成指数级别增长，实在痛苦！
对于几百万条记录的字段数据迁移，运行drush content-migrate-field-data 需要好几个G的内存，以前我们阿里云的ECS采用的16G内存，对于Web访问来说非常充裕，没有开启交换内存swap memory，但现在进行数据迁移只要同时运行2、3个进程就不行了。
前些天考虑再增加按量计费的ECS来专门跑数据迁移程序，除了CPU多核以外，对于内存的需求也非常巨大，想到是否可以用磁盘交换内存来替代，昨天找了些资料尝试了一下，还是可以的，这里记录一下临时设置交换内存的办法：
在磁盘上找合适的分区和目录，新建一个用于内存交换的文件myswap，块大小用1M，共16K块，也就是16G虚拟内存空间：dd if=/dev/xvdb1 of=/mnt/gb/myswap bs=1024k count=16384 按照swap memory要求的格式处理该文件：mkswap /mnt/gb/myswap 开启交换内存功能：swapon /mnt/gb/myswap 关闭交换内存功能：swapoff /mnt/gb/myswap
如果此交换内存以后需要长期用可以改为机器重启后自动启用（在/etc/fstab中添加/mnt/gb/myswap swap swap defaults 0 0），如果临时用一段时间不再使用了则可以删除上面创建的这个文件，腾出空间放置普通磁盘文件。
另外，启用虚拟内存后，虽然确实可以运行更多的PHP数据迁移进程，但机器运行效率、性能肯定有所下降，平均负载明显上升，如果对Web等正常服务有比较大影响的话，还是可以另外购买阿里云按量使用的临时ECS来专门做数据迁移，与生产环境隔离开来。
第二天补充：已经专门购买一台16核、16G的ECS专门来运行数据迁移，每个PHP进程需要5G左右内存，用上面的swap文件方式在一块硬盘上开启了交换内存，但当10多个PHP一起运行的时候，交换内存的动作变得频繁，硬盘IO就成了平均，一直占用100%，导致16核CPU无法发挥出来，就再购买了3块按量计费的云盘，挂接在这台ECS上（每台ECS最多挂接4块数据盘），做成3个交换内存分区：
使用fdisk来创建交换分区（假设 /dev/xvdc1 是创建的交换分区） 使用 mkswap 命令来设置交换分区： # mkswap /dev/xvdc1 启用交换分区： # swapon /dev/xvdc1
如果是多个交换分区和/或多个交换文件，可以设置不同的优先级别（数字越大越优先使用）：
swapon -p 1 /dev/xvdd1： 启用/dev/xvdd1并设置优先级别为1 swapon -p 1 /dev/xvde1： 启用/dev/xvde1并设置优先级别为1 swapon -s： 查看交换分区和交换文件统计
第三天再补充：16核16G内存，每个PHP进程大约需要5G左右的内存，使用虚拟内存后把PHP进程数量逐步加大，但到了一定数量后CPU的占比无法继续提高甚至开始下降，主要是因为交换内存访问磁盘太慢（虚拟内存是物理内存的大约5倍），多数进程都处于D延迟状态而不是R运行状态，CPU在IO和Sys切换分配上用了一些，Idle空闲也有一半多，这样下去CPU硬件无法发挥，整个运行进度无法加快。没有其它办法，今天早上果断加钱把内存加到64G，重启后再运行，这样运行20个进程左右，另外使用了大约30G虚拟内存（大约物理内存的50%），磁盘响应没有特别的压力，CPU可以跑到97%左右，这样才能持续发挥作用。
评论