在 hicloud 遭遇的狀況

最近因為遇到一些問題，所以開始 survey 往雲端發展的環境，目前在 hicloud 降價之後，價格到具有競爭力的階段(之前是 In/Out 合併計算，每 GB NTD 15，降價後只算 Out，每 GB NTD 3)，目前待了一個月左右，有一些有點麻煩的問題。

由於線上是 VM 環境(vmware)，所以資源共用是一件很合理的事情，但如果當我們的 VM 跟其他大戶放在一起，便會有很恐怖的事情發生。

圖中可以看到，Disk I/O 忽然在 12 點過後就進入瘋狂的 busy 狀態，在這個狀態下大部份的 CPU Time 都跑去做 IO Wait，所以 Load Average 莫名飆高，而整個跟 Disk 有關的動作都完全被卡死。

這個狀態持續了快 18 個小時，最後在連續三張 Ticket 以及好幾次電話之後才解決。

如果是一般的 Web Application，那只會暫時慢一下，沒有太大影響。但由於我的 Socket Server 是直接呼叫 MySQL C API ，在這裡則會直接 blocking，然後就會 Out of Service。

在這種 workload 都還算 micro 的狀況底下就出這種包，實在是有點誇張。

PS: 在當時，連一個大概十萬筆有 Index 的資料，下去做 query 限制三十筆輸出，都可以花上 20 多秒鐘？！ 這不會太誇張嗎？

所以當時對 ext4 的檔案系統有稍微調整一下。

1: 取消 access time 更新
2: 延長 write-back 的時間

(參考)

# 把 /etc/fstab 加上 noatime 跟 data=writeback

tune2fs -o journal_data_writeback /dev/sdaX

UUID=9ee7afff-654d-123c-b936-fe96354bec0c /               ext4    errors=remount-ro,noatime,data=writeback 0       1
# /etc/sysctl.conf 加上延長 writeback 時間

vm.dirty_writeback_centisecs = 360000

本來想把 ext4 的 journal 關掉，但是看了看好像不妥，尤其是需要 unmount/fsck ，我又是 root partition ，就放棄了。

看來目前能做的就是

1) 盡力讓 Database 有效率(快)一點，把不用的資料丟進 archive
2) 想辦法讓 server 對 MySQL 的存取變成 Asynchronous I/O，就算 MySQL 塞住也不要 blocking。
3) 求神拜佛希望 cloud 環境不要再出狀況了 (嘆)