在昨天針對“黑色30秒”問題的分析中,我們猜測Requests Queued上升是由於正在處理的請求出不去(到達不了客戶端)。今天我們結合IIS日志驗證這個猜測。 IIS日志中有一個重要的指標——time-taken,time-taken不僅包含了請求在服務端執行的時間,還包含了響應的內容 ...
搬到阿里雲上,對我們來說是重要的一步。雖然會遇到很多問題,但我們有信心解決這些問題 將遇到的實際問題與大家分享,也是一件很有價值的事。 這次遇到的問題涉及到IIS與阿里雲負載均衡所用的Tengine 阿里的開源Web服務器 。 我們的RSS站點遷移至阿里雲之后,發現http動態內容壓縮沒有生效 也就是下圖中的 Content Encoding: gzip 沒出現 。 RSS站點使用了阿里雲的負載均 ...
2013-03-19 13:53 10 3243 推薦指數:
在昨天針對“黑色30秒”問題的分析中,我們猜測Requests Queued上升是由於正在處理的請求出不去(到達不了客戶端)。今天我們結合IIS日志驗證這個猜測。 IIS日志中有一個重要的指標——time-taken,time-taken不僅包含了請求在服務端執行的時間,還包含了響應的內容 ...
今天下午15:11-15:13間出現了類似“黑色30秒”的狀況,我們用強大的IIS日志分析工具——Log Parser Studio進行了進一步的分析。 分析情況如下—— 先看一下Windows性能監視器中的問題表現: 然后用Log Parser Studio分析07:11:55與07 ...
在這篇博文中,我們拋開對阿里雲的懷疑,完全從ASP.NET的角度進行分析,看能不能找到針對問題現象的更合理的解釋。 “黑色30秒”問題現象的主要特征是:排隊的請求(Requests Queued)突增,到達HTTP.SYS的請求數(Arrival Rate)下降,QPS(Requests/Sec ...
在雲上,底層的東西你無法觸及,遇到奇怪問題時只能靠猜想,所以使用雲計算會鍛煉你的想像力。 (上圖中藍色是ASP.NET的Requests Queued,另外一個是HTTP.SYS的Arrival Rate) 昨天我們發現了一個重要的線索——“黑色30秒”到來時,最初的表現是請求出現排隊 ...
這篇博文記錄一下6月1日在阿里雲上遇到的奇怪的CPU 100%問題,希望多年以后能真相大白。 那天負載均衡(SLB)中只放了1台雲服務器(平時都放2台),由於是節假日,雖然只放了一台,但這台服務器的負載也沒有平時高。但在上午的時候突然出現了CPU 100%問題,然后切換到另外一台雲服務器恢復正常 ...
7月10日11:14接到一位用戶反饋,訪問園子時加載不了 common.cnblogs.com/script/jquery.js 這個文件。 由於這個域名用了阿里雲CDN,所以我們判斷可能是某個CDN節點出了問題,准備讓這位用戶ping common.cnblogs.com將CDN節點的IP反饋 ...
一周的萬里無雲是我們的第一個目標,這周天氣情況好轉,但昨天/今天下午依然有烏雲飄過。 昨天下午16:40~16:48左右,博客站點的兩台Web服務器突然出現CPU坐過山車的波動情況。 今天下午14:26~14:32左右再次出現CPU坐過山車的波動情況,之后又出現了幾次短時間的波動 ...
為了更好地分享我們解決“黑色1秒”問題的過程,在這篇博文中我們將專門描述一下“黑色1秒”問題的表現。 “黑色1秒”是我們使用阿里雲以來繼“黑色10秒”之后遭遇的最奇特、最詭異、最難以捉摸、最富有戲劇性的問題。 它有2個最顯著的特征: 第一個是最直觀的表現,在Windows性能監視 ...