通過IIS Request Filtering解決SQL Server CPU高的問題

標籤：

原文 http://www.peterviola.com/solving-sql-server-high-cpu-with-iis-request-filtering/

 

Top Queries by Total CPU Time

當CPU非常高的時候有可能你的條件反射就是重啟服務或者回收App Pools.SQL Server 2008 內建了非常棒的報表協助我們追蹤CPU的使用方式. 我使用Top Queries by Total CPU Time 報表. 如一項 右鍵服務名選擇相應的報表.

 

 Top Queries by Total CPU Time 報表會需要一點時間來產生. 通過報表能夠獲得是哪10個資料的查詢消費了最多的CPU. 通過報表我們發現這個伺服器上的一個資料庫的4個不同query消耗的大部分CPU. 

 

SQL Profiler and Database Tuning Advisor

現在我知道是哪個資料庫引發高CPU的問題了， 啟動 SQL Profiler 幾分鐘收集下資料.可以看到高的Reads是從 “Internet Information Services” 這個Appliation發出來的.

 

在將注意力集中在網站之前，我想看看通過 Database Engine Tuning Advisor  能不能提高效率 DTA 會分析通過提供的SQL指令碼 分析資料的一些行為,並且提高一個最佳化的方案（包括使用索引，分區...）. 通常通過 DTA  我們能提高 5-10 % 的效能改善. 在這個案例中我們能看到提高了97% 的改善!

 

 

Preventing SQL Injection with IIS Request Filtering

通過執行DTA提高的最佳化指令碼能降低一些CPU了. 然而我知道我們的網站有可能正在遭受一些可疑的訪問所以我使用 Log Parser 獲得一些網站的訪問情況.通過下面的query發現打量的訪問是正在利用querystring進行SQL注入.

logparser.exe -i:iisw3c “select top 20 count(*),cs-uri-query from ex140702.log

group by cs-uri-query order by count(*) desc” -rtp:-1 >file.txt

 

通常我們傾向於屏蔽攻擊的IP. 不幸的是一些老道的攻擊會使用大量不同的IP對你進行攻擊. 最佳的解決方案是通過 Request Filtering 過濾屏蔽這些惡意的請求.

 

通過 IIS Request Filtering 我們阻止了SQL注入攻擊. 使用下面Log Parser的查詢我們能看到所有請求的 http status codes .

SELECT STRCAT(TO_STRING(sc-status), STRCAT(‘.’, TO_STRING(sc-substatus))) AS Status, COUNT(*)

AS Total FROM w3svc.log to TopStatusCodes.txt GROUP BY Status ORDER BY Total DESC

 

當一個querystring被拒絕的時候Request Filtering 會使用 http substatus 404.18 . 通過下面的Log Parser report 能看到  50,039 個請求被屏蔽了.

 

通過IIS Request Filtering解決SQL Server CPU高的問題