2015年8月11日 星期二

艱辛一星期


過去的一個多星期實在活得很艱辛。無他,客人的一個活動推出市場,原本好好運作的服務器突然負荷不了。忙得不可開交。

按照客人上年同一個項目的配備,加上一點點的升級,原以為可以應負活動的需要,豈料在上線一個半星期後出現問題。最初是出現 MySQL 最大連線數量迫爆,由 250 不斷修改至 2500 都無法解決問題;唯有在程式接口方面進行優化,刪減多餘的 MySQL 連線及查詢;同時把各常用表格一分為二,將過期的數據遷入另一表格,令原來表格保持在較低的數據量。以上方法有點效用,可是過了一天,問題再次出現。在 netstat 上查看 HTTP 連線情況時,發現大量 SYN_RECV 阻塞了所有 HTTP 的通訊,就算重啟電腦也瞬間變成 SYN_RECV。向寄存公司查詢,回覆是 CPU 使用率達到 100%;我有一直在監察,明明最多是 95%...。然而,由於整個項目是建基於客人上年活動時的人流,在設計中沒有增加服務器的預算,當刻實在沒有辦法。後來想到把 Android 用戶分流,畢竟 Android 用戶人數最多,同時 Google Play 的審批過程只須三小時,可以在新版本中直接連接新服務器;得到客人的同意,於是立即進行。可是好景不常,兩天後相同情況出現,舊服務器在繁忙時間應付著每秒 600 人次,算是能接受的上限;而新服務器則達到每秒 900 人次,超出上限一半。那時真的沒有辦法,只能把一些次要的更新在繁忙時間中刪除,以縮短用戶的連接時間,增加服務用戶的數目。雖然解決不了問題,但至少能幫到一點忙。

今次人流之多,實在超乎想像。連續一個多星期搶修、更新及升級至深夜,零晨六點又起來監察服務器情況。雖然出了嚴重的狀況,但我對自己的處理及負責任程度實在非常滿意。從不斷支援、修改,到提供多一台服務器,及打後的一切為同步而做的功夫,我們沒有收取客人一分一毫。不過,客人不會這樣想,他們都認為是應該的,而且一定有很多怨言。試想想,如果跟香港寬頻申請 100GB 服務計劃,但自己用量太高,100GB 不夠用時,跟香港寬頻多拿 100GB 頻寬,你估要不要收費?可惜無計,畢竟我們都希望有翻單...。

沒有留言: