Amazon EC2 t1.micro 免費實例崩潰當機! 真的不夠用嗎? Amazon EC2 + Apache + PHP + MySQL 系統調教


amazon ec2

Amazon EC2 免費 t1.micro 的資源限制

Amanon EC2 試用期可以有一年的 t1.micro 實例的免費使用權,然而 t1.micro 免費實例的資源真的不是很夠,不管是 CPU 或者記憶體都不是很夠(內存只有613MB)。 在這種情況下,如果你的網站流量很小,基本上完全可以不用擔心,然而如果網站流量稍微多了一點,其實也沒多少,大約 300 PV/每天 以上,我認為資源就不太夠用,有可能是 CPU 也有可能是記憶體不夠,這沒有一定的規則,而且這兩者還會互相影響。

比如說如果記憶體不夠用,可能會需要 CPU 支援來做資料的交換(在磁碟間或者緩存記憶體間),這時候就會影響到 CPU 的效能。 反過來如果 CPU 使用率達到 100%,這時候整個系統的效能都會被拉低,Amazon EC2 免費的 t1.micro 實例本身還有一種機制,這種機制說起來對於 CPU 持續一段時間處於 100% 使用率的情況下的網佔非常不利,系統效能會急遽下降,這時候可能伴隨內存的剩餘空間太少,最後整個系統崩潰。

Amazon EC2 t1.micro 實例裡有一段說明如下:

We expect your application to consume only a certain amount of CPU resources in a period of time. If the application consumes more than your instance’s allotted CPU resources, we temporarily limit the instance so it operates at a low CPU level. If your instance continues to use all of its allotted resources, its performance will degrade. We will increase the time we limit its CPU level, thus increasing the time before the instance is allowed to burst again.

其實我之前就遇過這個問題,我曾寫過一篇文章說明 Amazon EC2 CPU 使用率 100% 的解決方法,當時確實解決了問題,然而當時的方法會造成另一個問題,就是系統 I/O 大增,超過免費限額,被 Amazon EC2收費。現在看來,當時沒有完全解決問題,造成現在更大的問題。 最近我的 Amazon EC2 系統又掛了,而且這一次狀況複雜的多。 掛掉後重啟,可以正常啟動,網站也可正常訪問,然而沒幾分鐘又再度掛點,這一次我知道問題的嚴重性,在調適幾個參數並且重啟系統幾次後,更糟的是資料庫徹底崩潰,MySQL 已經完全無法啟動,就算我重新安裝 MySQL 也是一樣的結果。 無奈只好重新建立一個 t1.micro 實例,並且重新調教參數。 下面我把正個調教過程記錄下來,對於這次的問題應該能有較好的監測方案。

Amazon EC2 t1.micro CPU 使用率長期達到 100%

amazon cpu 100% error

就在問題發生的當時,整個系統的 CPU 使用率經常處於 100%,在這種情況下系統很快就崩潰,我的系統看到的現象就是 MySQL 資料庫崩潰,當然網站也就訪問不了。

發生這種情況時只要重啟機器,通常可以恢復一陣子,但由於系統資源嚴重不足,很快的整個系統又會再次崩潰,這時間長短取決於網站所消耗的系統資源多寡。

當時我第一個想到的是會不會記憶體不夠用導致 CPU 使用率逐漸飆高? 所以我去追蹤記憶體的使用,我發現當時記憶體的 "空閒空間" 非常小,系統一啟動,所有進程就已經佔掉非常多的記憶體空間,其他所剩無幾(看下圖,綠色部分是剩餘的記憶體空間)。

system start memory map

所以第一件事就是看能不能降低記憶體佔用的空間

可以在 Linux 下命令 top 或者 ps -aux 來看看哪些進程佔用系統資源

linux ps command

可以發現 web server 所產生的 httpd 佔用多個進程,分析這些進程所佔用的 CPU 並不是很高,但是佔用的記憶體總合卻很高,畫面上有 12 個 httpd,總共佔用記憶體 56.3%,我在追蹤這些進程時,還發現有時候達到 20 個 httpd 進程,幾乎佔掉所有記憶體空間,而且 httpd 進程長期處於 10幾個降不下來,因此記憶體長期處於滿載的狀況。

這種情況下,當務之急就是降低 httpd 佔用記憶體的空間,然而這是個複雜的過程… 後面再講!

在實際調試之前有兩件事情先了解一下

(1) 系統調教的好工具 – phpmyadmin 系統資源監控

(2) top 命令看到的 CPU 使用率 us 只有小於 20%,但是Amazec EC2 ColudWatch 看到的卻是 100% 的問題。另一篇文章說明: LInux top 與 CloudWatch 不一致

第一個是個監控工具,後面會經常用到。第二個是個現象,先了解之後才能有效調教系統參數。

系統調教的好工具 – phpmyadmin 系統資源監控

phpmyadmin monitor

進入 phpmyadmin 後,點擊上方的 "狀態" 功能,可看到幾項監控的數據, 其中 "監控" 可以看到即時的系統負載

除了可觀察 MySQL 資料庫的使用狀況外,也可以時時監控系統的記憶體及 CPU 的使用情況

開始調教系統: 更改 apache 設置 httpd.conf

系統主要安裝了 Apache+PHP+MySQL 這些程序

要調試這部份就必須先了解 apache 的工作模式

可以參考這篇文章: Apache的prefork模式和worker模式

裡頭介紹了 prefork 與 worker 兩種模式的比較以及利弊

可以查看自己的 apache 服務用的是哪一種模式

大部分應該都是 prefork 模式

雖然 prefork 模式對於 cpu 及記憶體(內存) 的要求較高

但沒有明顯的理由要把 prefork 改為 worker 模式

然而就算是 prefork 模式,也是有可以調適的地方

打開 httpd.conf 設定檔,Amazon EC2 httpd.conf 路徑 /etc/httpd/conf/httpd.conf

更改如下

MaxKeepAliveRequest 從 100 改為 50

另外找到 prefork 的參數設定

ServerLimit 256
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 256
MaxRequestsPerChild 0

這些設置如果採用默認值的話,對於免費的 Amazon EC2 t1.micro 實例來說,負載太重了,記憶體很容易被消耗完畢

所以在有限的系統資源下,有必要適當的把數值改小

雖然有可能 "網站同時連線數量多時,要等待久一點的時間,這總比網站因資源不足而崩潰要好吧"

而且當下的連線數量自己應該很清楚,那就不難更改設定值為自己合適的數值

來看看設定值

(1) StartServers

服務器啟動時建立的子進程數量: 如果像 amazon ec2 免費的記憶體那麼小,這個值就盡量小吧。 設為 1 或 2 都可以,我設為 2

(2) MinSpareServers

空閒子進程的最小數量,理由同上,資源不夠就盡量小吧,這也設為 2

(3) MaxSpareServers

空閒子進程的最大數量,這個值也是盡量小,只要大於等於 MinSpareServers 就可以。 因為流量不大,不需要太多空閒進程在那邊等著

   

空閒進程太多將佔用過多記憶體,我設定成 8 ,後來進一步改成 5 ,這對記憶體的使用有很大的空間節省。

(4) MaxClents

同時間客戶端的最大請求數量(concurrent users)

這是最主要的參數設置,如果網站的流量不是非常高,這個值是不需要太大的,因為用戶同一時間上網站的數量如果有100個,相信你的網站流量已經夠大,應該不需要再放在 Amazon EC2 的免費實例中

(5) MaxRequestsPerChild

每個子進程生存期內可以處理的最大請求量

這個值不要設為 0,0代表無限制,永遠不會結束,那麼記憶體永遠不會釋放出來,本來系統資源就不多,時間久了,系統必然崩潰

我的設置如下

StartServers       2
MinSpareServers    2
MaxSpareServers    8
ServerLimit      256
MaxClients        64
MaxRequestsPerChild  256

另一個參數更改

KeepAliveTimeout 15

同一個 Client 同一個 connection, 等待下一個 request 的時間

這個數值也不要太大,我設成 15 秒,時間太長很多 connection 雖不再用但空間不會釋放出來。

觀察 httpd.conf 調教後的系統負載

我改完以後,將機器重啟,再觀察服務器的負載情況

phpmyadmin monitor phpmyadmin monitor

這兩張是 httpd.conf 更改前所抓的系統記憶體負載圖,第一張是開機後10分鐘,第二張是開機後18分鐘所抓

現象就是空閒內存急遽減少,已用空間逐步升高,並且居高不下,最後甚至空閒內存都快用完

再來看更改 httpd.conf 設定後的負載情況

phpmyadmin monitor

重啟後3分鐘,已用內存才用掉了 157MB,空閒內存有 314 MB

看到這張圖,才覺得比較放心,我也知道這次抓對問題了!

再來看看

phpmyadmin monitor

這張圖是開機後 14 分鐘的記憶體負載,狀況都還算不錯

phpmyadmin monitor

這是重開機後一個小時

可以看出記憶體使用起起伏伏,但過了 1 小時,仍然有這麼多的空閒內存,代表一些用過的記憶體有被釋放出來,沒有被一直佔用住

再來看一下尖峰時刻的表現

connection peak

同時連線數達到 11,記憶體負載瞬間飆高,不過還沒到頂(空閒內存仍有95.7 MB),峰值過後不久,記憶體就回復正常水平

接下來看一下 Amazon EC2 CloudWatch 的 CPU 負載狀況

amazon cloudwatch cpu monitor

amazon cloudwatch cpu monitor

可以看到除了少數一兩次 cpu 負載竄高到 65, 70 外其他都控制在 20%-40% 左右

短時間的極端情況,如下圖

phpmyadmin monitor

雖然 cpu 使用、資料庫查詢數、以及連線數都來到一個高峰,高峰過後仍然快速的回復到正常的資原始用水平

到這裡,終於可以稍微放心一點了

以上的更改實踐,可見更改設定後確實有效的避免了系統易於崩潰的問題

不過這不是徹底解決的辦法,若網站流量進一步升高,應該考慮換成系統資源比較好的服務器

其他系統調教

上面只談到 httpd.conf 的調整,要降低系統負載其實還有很多地方可以做,不過上面這是主要的問題所在,我調整過後基本上系統運行就回復正常,不過上面我也說了,這無法完全解決問題,因為系統資源仍然是有限的。

所以能優化的有時間還是要盡可能的優化,能省一點系統資源就是一點

其他的系統調整寫在另一篇文章中。 MySQL 調教及降低 CPU 使用率

以前也調整過一些地方,現在看來都沒完全解決問題,不過也值得去改善,有興趣可參考 (1) EC2 安裝 WordPress 每隔一段時間 MySQL 就當掉 (2) CPU 使用率 100% with WordPress (3) EC2 裡 MySQL 資料庫每隔一段時間就當掉的根本原因 (4) 防止搜索引擎訪問不必要的檔案及路徑

還有就是網站系統的調整,也可以降低部份的系統負載,可參考 "網站太慢?避免不必要的網路蜘蛛訪問,降低系統負載"

Amazon EC2 t1.micro 免費實例崩潰當機延伸閱讀

(*) Amazon EC2 免費實例: MySQL 崩潰之資料庫 log 查看及設定調教

(*) Amazon EC2 五分鐘快速新增實例

本文地址:Amazon EC2 t1.micro 免費實例崩潰當機! 真的不夠用嗎? Amazon EC2 + Apache + PHP + MySQL 系統調教
內容對你有幫助嗎? 臉書分享:
分享到:

發表迴響

您的電子郵件位址並不會被公開。 必要欄位標記為 *

*

您可以使用這些 HTML 標籤與屬性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

交換連結: Liang's Blog |