- 背景
近期被抓壯丁解決一個幾年前的系統故障，經過反復排查多次監控后終於成功解決，記錄分享一下心得吧！
- 故障描述
具體表現為在高峰訪問期間，IIS直接報服務器處理503。
- 系統部署
采用ARR實現的IIS Sever Farm進行負載均衡，將全省內部portal請求負載到兩台web服務器。
- 三板斧之一：對症下葯
既然已有錯誤信息：The serverRuntime@appConcurrentRequestLimit setting is being exceeded，那么根據這個信息進行檢索，發現是實時實時連接數超過默認配置導致，因此根據指引，將兩台web服務器的實時連接數設置為20000。
參考：http://www.jb51.net/os/windows/win2008/80751.html
結果：調整后當時，系統功能恢復，后續跟進發現在高峰期時系統仍舊無法提供服務，而且錯誤信息已經變化為502錯誤，如下圖。這個時候，搜索已經無法確切的找到問題了，是時候祭出我們的第二招了。
- 三板斧之二：望聞觀切
既然此坑廣大同胞沒有詳細解決攻略，那就我們自己肝起來吧！
- 首先，既然是web服務器無法服務那我們先檢查windows事件日志吧：排查結果日志無異常錯誤信息。
- 其次，檢測IIS日志文件，檢索是否存在502的日志情況（這個地方不是很確定IIS在拒絕服務后還會不會記錄訪問日志,姑且檢查一下,后續可以重現一下，TODO：哈哈哈哈）：結果，無502的日志記錄，簡直吐血。http://www.cnblogs.com/mincyw/p/3425468.html
- 基於在web服務器本地host訪問無任何異常，且之前503的異常跟實時連接數有關系，因此，檢測負載均衡的實時情況，發現兩台服務器一台實時連接數達到1W1+，另一台6000+。（其實這里已經是病症所在，實時連接數這么大，肯定是有請求堵住了，但是當時沒有識別出來，功力還不夠深啊！）排查結果：以為是均衡策略問題，調整均衡策略！結果隔天照樣502！！！
- 非高峰期觀察系統訪問情況，發現某個頁面響應特別慢，且偶爾有超時的風險！！排查結果：懷疑跟數據量有關系，備份后清理14年以前的數據。
在清理完數據后，神奇的事情發生了！！訪問高峰期時，兩台web服務器的實時連接數由1W1+和6000+，都斷崖式地降到100！！！且幾天下來的監控發現系統已經正常提供服務！！！
總結：由於某些sql查詢慢，導致請求響應時間過長，導致IIS處理隊列一直堵塞，最終觸發503實時連接數超出及502無效響應！
- 三板斧之三：庖丁解牛
既然定位到數據庫查詢慢的問題，那想辦法讓他快起來吧！
- 治標：備份清理數據。（視系統重要性，如需要快速恢復服務，采用此辦法先提供正常服務）
- 治本：sql優化。（索引優化、檢測查詢計划、索引碎片整理等，但是優化並不是一朝一夕，需要時間，所以一般先治標，再治本）
- 總結
遇到故障並不可怕，可怕的是不知道怎么下手解決故障！！
PS：下次遇到503/502時，優先排查數據庫sql執行效率吧！嘿嘿嘿：http://www.cnblogs.com/jonhson/archive/2011/09/24/2188304.html