網頁

2012年10月12日 星期五

在 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 環境不要再出狀況了 (嘆)