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%左右，這樣才能持續發揮作用。
评论