昨天對“黑色n秒”問題的最終猜想以失敗而告終,從而讓我們結束了被動猜想階段,進入了主動進攻階段——出招。 今天出第一招——用C#寫個小程序,讓其在每個CPU核上運行一個線程,不讓任何一個CPU核進入空閑(idle)狀態,以進一步排除CPU idle引起的“黑色n秒”。 在這一招中,借助 ...
程咬金有三板斧,我們有三招。在這篇博文中我們要出第三招,同時也意味着昨天在 希望的田野 上的第二招失敗了。 前兩招打頭 CPU 不湊效,這一招要換一個部位,但依然要堅持攻擊敵人最弱 最忙最累 部位的原則。那除了CPU,最忙最累的部位是哪里呢 對於Web服務器來說,毫無懸念,當然是網卡。而且阿里雲的雲服務器,所有的網絡負載都集中在一塊內網網卡上,SLB 負載均衡 用它,OCS 緩存服務 用它,RD ...
2014-05-21 21:28 17 13473 推薦指數:
昨天對“黑色n秒”問題的最終猜想以失敗而告終,從而讓我們結束了被動猜想階段,進入了主動進攻階段——出招。 今天出第一招——用C#寫個小程序,讓其在每個CPU核上運行一個線程,不讓任何一個CPU核進入空閑(idle)狀態,以進一步排除CPU idle引起的“黑色n秒”。 在這一招中,借助 ...
雖然昨天的第一招失敗了,但是從失敗中我們學到了與多核CPU相關的Processor Affinity(處理器關聯)的知識。 既然我們可以讓.NET程序的不同線程運行於指定的CPU核,那是不是也可以讓IIS應用程序池的進程w3wp運行於指定的CPU核? 雖然看起來“黑色n秒”似乎與w3wp ...
為了更好地分享我們解決“黑色1秒”問題的過程,在這篇博文中我們將專門描述一下“黑色1秒”問題的表現。 “黑色1秒”是我們使用阿里雲以來繼“黑色10秒”之后遭遇的最奇特、最詭異、最難以捉摸、最富有戲劇性的問題。 它有2個最顯著的特征: 第一個是最直觀的表現,在Windows性能監視 ...
如果說2013年雲計算之路的主題是“踩坑”,那么2014年我們希望雲計算之路的主題變成“填坑”——當然填坑是阿里雲來完成的,我們只是見證曾經的坑坑窪窪變成平坦大道。 15號(周四)晚上我們發現了SLB會話保持的坑,16號晚上阿里雲成功定位並進行修復,這兩天正式發布后會填平這個坑。這次從踩坑 ...
在雲上,底層的東西你無法觸及,遇到奇怪問題時只能靠猜想,所以使用雲計算會鍛煉你的想像力。 (上圖中藍色是ASP.NET的Requests Queued,另外一個是HTTP.SYS的Arrival Rate) 昨天我們發現了一個重要的線索——“黑色30秒”到來時,最初的表現是請求出現排隊 ...
雲上真是無奇不有,這兩天我們什么也沒動,“黑色30秒”招呼不打一聲就走了,而來了一位不速之客——“黑色1秒”;就寫了一篇博文,30秒就變成了1秒,看來多寫博客是硬道理。 在上篇博文的評論中有人說——就30秒,有必要這么較真嗎——當時想,別說30秒,哪怕1秒,我們也會較真。結果說1秒,1秒就來 ...
“黑色1秒”問題經過一個多月的艱苦奮戰,今天終於取得了重要進展!我們終於有了足夠的數據證明不是微軟IIS的問題,就是阿里雲Xen虛擬機的問題。 這篇博文分享的是我們如何進行證明的,而且這次證明連Window性能監視器都不需要。 下面我們來分析一下今天10:37:35出現的“黑色1秒”(下面所用 ...
針對Web服務器“黑色30秒”問題(詳見雲計算之路-阿里雲上:Web服務器遭遇奇怪的“黑色30秒”問題),經過分析,我們准備從這個地方下手——為什么會出現\ASP.NET\Request Queued大於0的情況(為什么請求會排隊)? 首先, 通過Windows性能監視器去觀察,看能不能找到 ...