雲計算之路系列博文分享的是我們將網站從IDC機房遷移至雲計算平台的實際經歷,目前即將遷入阿里雲,這次分享的是在正式遷移前兩台雲服務器出現的奇怪問題。 其中一台的故事是這樣的: 博客園找找看的后台服務(建索引,查找索引)很早就遷入阿里雲的一台雲服務器上,一直正常,Windows性能監視器中 ...
今天下午訪問高峰的時候,主站的Web服務器出現奇怪的問題,開始是 台 核 G的雲服務器 ECS ,后來又加了 台 核 G的雲服務器,問題依舊。 而且 台服務器特地使用了不同的配置: 台是禁用了虛擬內存的臨時磁盤雲服務器, 台是啟用了虛擬內存的臨時磁盤雲服務器, 台是禁用了虛擬內存的雲盤雲服務器。這樣排除了磁盤IO與虛擬內存的原因。 問題的表現是這樣的 以下監視截圖來自Windows性能監控器Per ...
2014-04-22 17:21 35 6683 推薦指數:
雲計算之路系列博文分享的是我們將網站從IDC機房遷移至雲計算平台的實際經歷,目前即將遷入阿里雲,這次分享的是在正式遷移前兩台雲服務器出現的奇怪問題。 其中一台的故事是這樣的: 博客園找找看的后台服務(建索引,查找索引)很早就遷入阿里雲的一台雲服務器上,一直正常,Windows性能監視器中 ...
在雲上,底層的東西你無法觸及,遇到奇怪問題時只能靠猜想,所以使用雲計算會鍛煉你的想像力。 (上圖中藍色是ASP.NET的Requests Queued,另外一個是HTTP.SYS的Arrival Rate) 昨天我們發現了一個重要的線索——“黑色30秒”到來時,最初的表現是請求出現排隊 ...
在昨天針對“黑色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 ...
針對Web服務器“黑色30秒”問題(詳見雲計算之路-阿里雲上:Web服務器遭遇奇怪的“黑色30秒”問題),經過分析,我們准備從這個地方下手——為什么會出現\ASP.NET\Request Queued大於0的情況(為什么請求會排隊)? 首先, 通過Windows性能監視器去觀察,看能不能找到 ...
雲上真是無奇不有,這兩天我們什么也沒動,“黑色30秒”招呼不打一聲就走了,而來了一位不速之客——“黑色1秒”;就寫了一篇博文,30秒就變成了1秒,看來多寫博客是硬道理。 在上篇博文的評論中有人說——就30秒,有必要這么較真嗎——當時想,別說30秒,哪怕1秒,我們也會較真。結果說1秒,1秒就來 ...
為了更好地分享我們解決“黑色1秒”問題的過程,在這篇博文中我們將專門描述一下“黑色1秒”問題的表現。 “黑色1秒”是我們使用阿里雲以來繼“黑色10秒”之后遭遇的最奇特、最詭異、最難以捉摸、最富有戲劇性的問題。 它有2個最顯著的特征: 第一個是最直觀的表現,在Windows性能監視器 ...