雲計算之路-阿里雲上：“黑色1秒”問題與2009年Xen一個補丁的故事
在之前對“黑色1秒”問題的分析博文中，我們將最大嫌疑對象鎖定在了Xen，在這篇博文我們將從Xen的角度進行分析。也許有人會問，為什么不知道天多高地多厚地去研究不屬於自己范圍的問題？只因我們對一個問題的強烈好奇心——究竟是不是我們用Windows的錯？ （注1：文中所說的Xen補丁問題只是提供一種 ...
原文：雲計算之路-阿里雲上：基於Xen的IO模型進一步分析“黑色0.1秒”問題
在發現雲服務器讀取OCS緩存的 黑色 . 秒 是發生在socket讀取數據時，而且是發生在讀取開始的字節，甚至在socket寫數據時 比如寫入緩存key 也會出現超過 ms的情況，我們的好奇心被激發到一個新的高度。 根據我們的實測，在雲服務器上創建一個新的TCP連接通常也不過 ms左右。在黑色 . 秒期間，TCP包已經到達網卡，從網卡讀到內存中竟然超過 ms，這太不可思議了 后來想想，如果.Ne ...
2014-05-13 15:24 7 3339 推薦指數：
相關推薦
雲計算之路-阿里雲上：什么是“黑色1秒”？
為了更好地分享我們解決“黑色1秒”問題的過程，在這篇博文中我們將專門描述一下“黑色1秒”問題的表現。 “黑色1秒”是我們使用阿里雲以來繼“黑色10秒”之后遭遇的最奇特、最詭異、最難以捉摸、最富有戲劇性的問題。 它有2個最顯著的特征： 第一個是最直觀的表現，在Windows性能監視 ...
雲計算之路-阿里雲上：對“黑色30秒”問題的猜想
在雲上，底層的東西你無法觸及，遇到奇怪問題時只能靠猜想，所以使用雲計算會鍛煉你的想像力。 （上圖中藍色是ASP.NET的Requests Queued，另外一個是HTTP.SYS的Arrival Rate） 昨天我們發現了一個重要的線索——“黑色30秒”到來時，最初的表現是請求出現排隊 ...
雲計算之路-阿里雲上：讀取緩存時的“黑色0.1秒”
看到標題中的“0.1秒”，你也許會呲之以鼻：不會吧，0.1秒也要計較，不是吃飽撐着，是沒吃飽也撐着。 依然沒撐着！在memcached應用場景中，響應速度是處於1ms級別的，0.1s可是比1ms慢了100倍啊。 如果你不相信1ms級別，請看這篇文章（微博CacheService架構淺析）中 ...
雲計算之路-阿里雲上：原來“黑色0.1秒”發生在socket讀取數據時
在昨天的博文（雲計算之路-阿里雲上：讀取緩存時的“黑色0.1秒”）中我們犯了一個很低級的錯誤——把13ms算成了130ms（感謝陳碩發現這個錯誤！），從而對問題的原因作出了錯誤的推斷，望大家諒解！ 從中我們吸取到了一個教訓：趁熱打鐵要小心，容易失去冷靜，作出錯誤的判斷。 今天我們痛定思痛，用了 ...
雲計算之路-阿里雲上：結合IIS日志分析“黑色30秒”問題
在昨天針對“黑色30秒”問題的分析中，我們猜測Requests Queued上升是由於正在處理的請求出不去（到達不了客戶端）。今天我們結合IIS日志驗證這個猜測。 IIS日志中有一個重要的指標——time-taken，time-taken不僅包含了請求在服務端執行的時間，還包含了響應的內容 ...
雲計算之路-阿里雲上：借助IIS Log Parser Studio分析“黑色30秒”問題
今天下午15:11-15:13間出現了類似“黑色30秒”的狀況，我們用強大的IIS日志分析工具——Log Parser Studio進行了進一步的分析。 分析情況如下—— 先看一下Windows性能監視器中的問題表現： 然后用Log Parser Studio分析07:11:55與07 ...
雲計算之路-阿里雲上：從ASP.NET線程角度對“黑色30秒”問題的全新分析
在這篇博文中，我們拋開對阿里雲的懷疑，完全從ASP.NET的角度進行分析，看能不能找到針對問題現象的更合理的解釋。 “黑色30秒”問題現象的主要特征是：排隊的請求（Requests Queued）突增，到達HTTP.SYS的請求數（Arrival Rate）下降，QPS（Requests/Sec ...