誰動了我的CPU?!
云最重要的一個特色就是在多個用戶中共享資源。缺少了共享和資源優化的能力,云服務供應者就無法給業務提供可擴展性及對“規模經濟”的支持。IaaS在包含了計算能力、儲存和網絡設施的同時還包含了它的“云魔法”。而這些資源的使用必須經過充分優化用以滿足用戶需求,因此他們只能在用戶中共享。
什么是Steal Time?
衡量服務器對CPU利用的基本標準就是閑置能力 —— CPU的空閑量。CPU的使用率由下面幾種分配決定:
User —— 運行的應用程序
System —— 操作系統
Interrupt —— 硬件中斷
Wait —— 等待I/O操作的完成
Steal —— 與虛擬機無關的周期
Idle —— 未進行任何作業
Steal Time(ST)通常還被稱作“Stolen CPU”,存在于虛擬計算環境 —— CPU使用內部虛擬機運行任務的時間,由Hypervisor將CPU周期分配給其他“外部任務”產生;而這些外部任務很可能就是你吵鬧的鄰居(云端共享同一片資源的用戶)遞交的。
AWS上的Steal Time
通過在AWS社區上的研究發現,在CPU達到峰值的一段時間后:系統會自動的將CPU收縮至一定的使用比例,那么你剩下的CPU就被“竊取”了。這種情況通常是云端對自己的保護,以避免崩潰的威脅。
你可以找到更多關于AWS上Micro Instance信息的常見問題解答:“Micro實例會一直提供少量的CPU資源;而當額外的周期空閑時,AWS允許你將CPU資源擴充到2 ECU。它們非常適合那些吞吐量較低的應用程序;以及定期擁有大量的計算周期,而其它時間只為后臺進程和守護進程提供少量CPU資源的網站”。
在亞馬遜開發者社區,你可以發現:
“舉個例子:當我想做一個“yum update”的時候,系統在一分鐘之內都沒有響應;預想中這個操作會耗時3到5分鐘,通常也需要這么久;但是今天只花了30秒到1分鐘左右時間。”

亞馬遜并沒有詳述Xen配置,盡管它們說:“實例根據CPU的使用率在本質上劃分為兩個級別:基礎的低標準等級、以及在這個等級上擁有短暫飆升能力的等級。”(點擊查看更多了解我獲悉的)使用標準的監測工具去監測CPU可能會誤導云用戶,舉個例子:由于虛擬化層在底層的基礎設施上,Linux實例不會報告CPU的正確使用率。為了得到EC2基礎設施上正確的CPU利用率,云用戶只能使用CloudWatch來測量。
另一個影響CPU使用率的重要方面在于任務的模型。這里必須區分兩個負載模型:批處理和實時。前者能夠更大程度上容忍資源的短缺,并可以等待一段可觀的時間。批處理模型描述的任務一般都會生成一個穩定的使用率或者集合成一個總的CPU使用率,所以一旦CPU負載過重,批處理將會被順延。而實時模型從不會被順延,并且云供應商也會約束它的負載。此外,像亞馬遜AWS這些云供應商更趨向去設計更多的批處理負載模型來控制它們服務器的負載。
為了更好的利用AWS的Micro Instance,你必須有能力控制你的在線資源。當然你也可以去做網絡服務器配置的嘗試,舉個例子:限制用戶數量。你需要使用S3來儲存靜態文件,比如:圖像、視頻和音頻。使用其他AWS服務擴充你的應用性能需求可以將一些負載轉移到其他的云資源上,從而降低你EC2實例的CPU消耗負載。總而言之,這里的重點不在于資源的多少,而是能使用有效的手段去控制負載的平衡。