秋色園引發CPU百分百命案的事件分析與總結

前幾天寫過一篇文章：秋色園CPU百分百的原因分析

由於上文有介紹了一些前因后果和中間過程及基礎的內容，所以怎么發生的，中間大體做了什么檢測，就不重復寫了，下面寫一些事情的后續發展。

在解決完上文說的，搜索引擎引發的命案后，有網友給秋色園做了下壓力測試，鏈接數直上1-2千，導致CPU掛了。

一：URL緩存可能存在的攻擊命案：

 

當時我一路正遠程用SQL事件探查器和性能計數器觀看着，發現IIS並發鏈接數直接上千，不停的產生SQL語句， 導致數據庫占用CPU直接滿了，網站掛了打不開。

從這里，我發現了系統上存在一些邏輯上的不和諧：

比如：http://www.cyqdata.com/tech/cate-19，秋色園網站的緩存，基本上是基於URL來緩存的。

而對方發起的壓力測試，則並發產生了數百個： http://www.cyqdata.com/tech/cate-19-Nxxxxxxx這樣的網址。

由於URL的變化，所以不停的產生新的頁面查詢，造成數據庫不斷的查詢，持續的並發查詢數據庫CPU直接滿了，掛了。

對於這個問題，我進行了全面的URL參數處理，在未讀取數據庫之前，就判斷參數的合法性，和邏輯上的調整，把跳轉檢測的函數放在前面，其它讀取的放后面，這樣無效的地址也不會引發不必要的數據庫語句查詢或邏輯。（全站有好幾個，都存在這種情況，都同樣的方式處理了）。

根據這個規則，大伙就要注意了，根據URL地址緩存的邏輯，或動態生成靜態頁面邏輯的，還是要細心的檢測一下。 

 

二：DZ論壇的小檢查

 

現在有好多論壇，好多個人站都運行在VPS或虛擬機上，我跑過去看了下，試圖想找到一些動態處理的頁面，來進行下壓力測試，結果發現除了登陸發貼等少數動態的，幾乎全站靜態。

通常的說，搜索這塊，通常都是動態的，而且也比較消耗時間的，我一搜，發現，真聰明，DZ直接引用了Soso的搜索服務，把壓力轉移了。

 

 

三：網站並發壓力測試工具

 

好多人問題是用的什么工具，網友用的是Apache自帶的ab.exe，只要安裝了Apache，目錄下就有這工具了，一條簡單的命令行就能簡單的對某網址進行壓力測試。

不過有個限制，一般最多是64個並發，比在線並發測試網站默認提供的15個免費並發好多了，Linux下有幾篇文章有說修改並發數的，卻沒找到在windows下怎么修改並發數上限的方法，有知道的說一聲。

 

 

四：一個未知的線程死鎖：

 

這個問題，在本地時測試時出現過幾次，出現的時候，我也很積極的Dump，通過processxp工具也能看到2個線程各占20%，持續時間長，就是不下來，然后沒有更多信息了。

Dump是個悲催的事，真心不擅長，來來回回幾個命令，就是不見啥信息，幾年前我Dump過一次，幾年后，還是Dump在那水平，悲催的歲月，發現不了問題所在。

折騰許久許久后，放棄了，后來一直在大力重構，好多代碼邏輯刪除了，重寫了。

之后，這問題也失蹤了，許久也沒再出現過，不知道是不是意外的存在被我刪除的代碼中。

 

 

 

五：系統磁盤空間不足引發的命案：

 

剛剛有微博用戶給我留言，說秋色園打開報錯，提示硬盤空間不足，我趕緊遠程登陸看了一下，C盤只剩下128K，-_-.....

先臨時清了點東西，出了一百多M，恢復了系統運行，然后找是誰吃了硬盤空間：

不看不知道，一看嚇一跳，原來是IIS日志吃了近7個G的日志（VPS上一般C盤就10G）

我打開日志，看都寫了啥日志。。一看嚇傻了，都是壓力測試時產生的請求，一個日志近500M。

根據這個情況，我在想，對於小站點，不斷用多線程發送請求，造成日志快速增長，把對方空間給擠死，哈哈，好邪惡！！！

人生有兩出悲劇，一者執意尋死，一者無力求生，你全包了。