如果說2013年雲計算之路的主題是“踩坑”，那么2014年我們希望雲計算之路的主題變成“填坑”——當然填坑是阿里雲來完成的，我們只是見證曾經的坑坑窪窪變成平坦大道。
15號（周四）晚上我們發現了SLB會話保持的坑，16號晚上阿里雲成功定位並進行修復，這兩天正式發布后會填平這個坑。這次從踩坑到填坑的過程是最痛快的一次。
接下來我們的目標鎖定在“黑色n秒”（剛發現一個英文說法：stuck for x seconds）這個坑我們最多、最神秘、最詭異的坑。
受“雲計算之路：2009年Xen一個補丁背后那不為人知的故事”一文的啟發，在這篇博文中，我們要對“黑色n秒”的原因做出一個最大膽的猜想，也希望是最終猜想！我們的猜想是——我們遇到的“黑色n秒”問題，不管是黑色10秒、30秒、1秒、5秒還是這兩天剛剛發現的0.5秒，都是背后同一個原因在不同觸發條件下的不同表現。
那這個背后的原因是什么呢？如果用最簡單的話來表達，就是CPU睡過頭了。如果哆嗦一點，就是CPU的某個核因為空閑進入睡眠狀態（C-states），后來需要它工作時，Xen想借助另一個CPU核來喚醒它，結果由於某種未知因素造成睡眠中的CPU核沒被喚醒或者負責喚醒的CPU核偷懶了。此時此刻，黑色n秒就開始了，只至睡眠中的CPU核被外部中斷喚醒。
從這個猜想中可以看出，如果所有的CPU核都在忙碌，就不會觸發這個問題。是的，當我們得到這個猜想時，有點哭笑不得——之前由於遭遇CPU跑高、CPU波動問題，本來4核就夠了。我們特地買了8核，通常有4個核都閑着，從而更容易觸發這個問題。
那換成4個核是不是會解決問題呢？不會，只是發生的頻率會低一些，因為網站訪問有高低峰，在低峰時也會有CPU核閑下來。
那有沒有辦法從根本上避開這個問題？有！目前為止我們發現一個唯一的解決方法，就是——堅決不讓CPU進入睡眠狀態，即使沒活干，也要呆着隨時待命。要實現這個，需要進入物理機的BIOS關閉CPU的C-states。而為此要付出的代價是支持電力事業的發展。
你也許會問這個最終猜想及解決方法究竟靠不靠譜呢？請看下面3個在網上發現的案例。
第一個案例：Citrix論壇上的一個帖子——Xenserver 6.2 intermittent ping response delays
用的是DELL R820+XenServer 6.2，遇到的問題是：ping虛擬機有時會出現響應時間高達500ms左右的異常情況（在時間點上與我們遇到的“黑色0.5秒”對應）。
Intermittently we see a large response time and followed by the normal response time <1ms, this gradually decreases from 500ms back to 1ms then jumps to 500ms and starts decreasing again.
后來是通過進入這台機器的BIOS禁用C1E和C States解決的：
Manged to resolve this by making the following changes on the R820 BIOS:
System BIOS Settings -> System Profile Settings
Changed C1E to Disabled
Change C States to Disabled.
這個案例中最值得關注的地方是所用的物理服務器是DELL R820，CPU是Xeon E5-4600；而我們用的阿里雲雲服務器的物理機的CPU是Xeon E5-2630。雖然型號有差異，但都是Ivy Bridge架構，更關鍵的是電源管理功能是一樣的，用的都是Intel Turbo 2.0（詳見這里）。所以我們推測，如果E5-4600在電源管理上存在缺陷，那么E5-2630也同樣存在，該案例中所用的禁用C1E和C States的方法也可能也適用於我們的場景。
第二案例：Citrix支持中心的一篇文章——Hosts Become Unresponsive with XenServer 5.6 and above on Nehalem and Westmere CPUs
用的是Nehalem與Westmere架構CPU+Xen Server 5.6，遇到的問題是虛擬機隨機死鎖，問題通常發生在CPU長時間處於空閑狀態（空閑的結果自然是進入睡眠狀態）之后：
Hosts that are experiencing this issue will often have been largely idle for a period leading prior to the lockup.
也是通過在BIOS中禁用C-states（同時也禁用了Turbo Mode/Turbo Boost option）解決的。
To resolve the issue, complete the following procedure:
- In the BIOS menu, set the value for the C-states option to Disabled.
- In the BIOS menu, set the value for the Turbo Mode/Turbo Boost option to Disabled.
- If the server BIOS has power management options that leave power management to the BIOS rather than the operating system, such as Dell's Active Power Controller or HP’s Power Regulator, also disable this by setting the power management option to OS Control.
這個案例中，最值得關注的是文章中的Problem Cause部分，文中說Nehalem與Westmere CPU架構引入了新C-states特性，但存在缺陷，文中所遇到的問題就是這個缺陷引起的。
但我們所用的Xeon E5-2630不是這兩個CPU架構，不受這個缺陷影響。但從中可以知道物理CPU在電源管理上的缺陷是會引起虛擬機死鎖問題（黑色n秒也可以說成是死鎖）。
第三個案例：stackexchange上的一個問答——BUG: soft lockup - CPU# stuck for x seconds
用的是亞馬遜AWS EC2(也是Xen)+CentOS，遇到的問題是某個進程會卡住10秒或者更長時間，與我們遇到的黑色10秒很相似。
這位提問者最終沒有說是如何解決這個問題的，但回復中有人說
Disabling c-states worked for me. – Andrew
我們猜測這位回復者遇到了類似問題，並通過禁用C-States解決了。
從這個案例，我們進行了這樣一個推測： stackexchange上的這個問題是在2013年5月27日提出的，亞馬遜AWS EC2的虛擬機環境與阿里雲ECS的虛擬機環境很接近，EC2上出現的這個問題在ECS上重演的可能性很大，而我們遇到的黑色n秒問題可能就是一種重演。既然有人通過禁用C-states解決了問題，我們為什么不嘗試一下呢？
【我們的嘗試】
我們的嘗試是在虛擬機中在Windows層面禁用CPU C-states，但前提條件是物理機在BIOS中設置了將CPU電源管理控制權交給操作系統。想想這個可能性太小了，因為一台物理機中跑着多台虛擬機，如果控制權交給了操作系統，假如這台虛擬機禁用了C-states，那台虛擬機沒有禁用，CPU該聽誰的。
雖然可能性微乎其微，我們還是要試試。我們通過在Windows注冊表中添加一個針對CPU的Capabilities項禁用了C-states（來自superuser）：
reg add HKLM\System\CurrentControlSet\Control\Processor /v Capabilities /t REG_DWORD /d 0x0007e066
但測試結果顯示，黑色n秒問題依舊。於是，只剩下唯一的希望。
【唯一的希望】
現在唯一能驗證我們的最終猜想、唯一能解決“黑色n秒”問題的希望就是——進入物理機的BIOS，禁用CPU C-states。
【更新】
從阿里雲得到的最新消息，物理機的BIOS是關閉C-states的，我們的最終猜想失敗。
接下來唯一的希望就寄托於阿里雲對這個問題的繼續研究。