昨天晚上，我們向博客站點的負載均衡中又增加了一台8核CPU的雲服務器，一共用24個核跑博客站點。
今天早上，我們修改了程序，記錄從memcached與nosql中讀取數據的耗時，以確認是不是與memcached/nosql有關。每次故障時，阿里雲都要懷疑memcached與nosql，在這上面耗費了很多的時間。
另外，為了進一步減輕Web服務器的CPU負擔，我們將memcached從Web服務器中獨立了出來。
今天早上9:30的高峰扛了過去，哪知10:00左右問題又開始出現。
（紅色曲線表示的是CPU占用率）
故障期間CPU平均占用率在20%以上。我們增加一台雲服務器的目的就是想將CPU平均占用率控制在20%以下，在9:30訪問高峰沒出問題的時候CPU平均占用率就在20%以下。每次故障，CPU占用率是最直接的反映。這也是我們用了阿里雲之后發現的一個很大的不同，以前用物理服務器，我們的Web服務器CPU平均占用率長期在80%以上，一點問題沒有。
故障期間單台雲服務器的IIS並發連接數由平時的10以內達到我們設置的5000的上限（503錯誤就是這個引起的），IIS並發連接數暴增由兩個可能的原因：一個可能是SLB（負載均衡）出問題扔過來大量額外的請求，一個可能是Web服務器處理能力急聚下降，很多請求得不到處理，越積越多。
我們采用一個方法進行了驗證。不走SLB，直接用單台雲服務器跑博客站點；如果是SLB的問題，避開它之后問題應該立即緩解。一從SLB切換到單台雲服務器，這台雲服務器的IIS並發連接數就串到了上萬（IIS的連接數限制已取消），對於這么大的連接數，單台雲服務器毫無還手之力。以前我們用自己的物理服務器，也是8核CPU，跑的站點還比現在多，2萬的IIS並發連接也應對自如。通過這個驗證說明了SLB沒問題，說明了單台雲服務器（虛擬機）雖然用的是2.4G的物理CPU（Azure的虛擬機CPU也只有1.6G），但實際處理能力大打折扣。
在故障期間memcached與nosql的數據讀取速度正常，即使禁用memcached與nosql，問題依舊，所以問題與memcached/nosql無關。
通過對今天故障的分析，我們的判斷是：雲服務器（虛擬機）的CPU處理能力是最大的嫌疑。
我們應對措施是：進一步減輕單台雲服務器的負擔，將單台雲服務器的CPU平均占用率控制在20%以內，目前已經又增加一台8核的Web服務器，用32個核跑博客站點。
相關博文：博客園與啊里雲的故障假設：高需與低配