Google已經實現世界級數據中心服務器監控，新的技術可以監控世界范圍內每台服務器上的每個任務；其最終目的是通過這些數據有選擇對進程進行干預、甚至是關閉該進程讓同CPU上的其它進程得以運行。
搜索巨頭在技術論文中詳細的描述了這一世界級監視技術的實現方法，相信使用大型基於
Linux雲計算基礎設施的機構都會對此感興趣。
論文中寫道：
性能隔離是雲計算的主要挑戰。不幸的是，Linux缺少對共享資源（比如：處理器緩存、存儲器總線等）中性能干擾的防御；這樣的話，公有雲中的應用程序將無法避免來自鄰居們的干擾。
CPI方案使用從硬件性能計數器獲得的CPI（cycles-per-instruction，平均指令周期數）數據檢測問題，中斷或者關閉“問題”進程從而達到預期的效果，當然它會根據相同作業中大量任務數據認知這個任務的反常與否。
本質上講，CPI讓Google可以在集群上萬個CPU核心中隔離單個核心上的單個性能低下任務，對這個任務進行檢查並進行操作，而造成的CPU開銷甚至不到0.1%。它並不需要特殊的硬件支持，唯一的軟件依賴恰是使用Linux。
CPI允許Google收集任何指定指令的預期CPU CPI，從這些數據中分析出標准的資源配置文件，然後使用這些標准的配置文件去幫助網絡巨頭確定哪些任務比一般情況下耗費了更多的CPI，從而解放與這些任務使用相同CPU的其它進程。
Google稱，其絕大多數機器上都運行著多任務。作業的處理類型分為實時處理和批處理兩種，同時這些作業由大量的任務組成。Google服務器上96%的任務都會與至少10個的任務組成一個作業，而87%左右的任務會與100或以上的任務組成一個作業。
但是這些任務可能會相互干擾，導致處理器緩存和內存分配問題，造成應用中的某個任務延時飙升——這正是Google不惜一切代價都想避免的問題。
為了實現任務流下每個處理器的控制，Google使用CPI監視所有運行的服務器。通過測量處理器硬件計數器，然後用CPU_CLK_UNHALTED.REF除以INSTRUCTIONS_RETIRED來獲得CPI數據。
通過計算模式下的perf_event工具，Google每分鐘都會收集一個長為10秒周期的數據。系統中總CPU的開銷低於0.1%，並且不會對延時產生影響。
因為集群需要跨大量的平台運行，CPI的目的在於體現各種平台下的CPU運行情況。CPI的值通過每台機器上的agent進行本地分析和測量。agent通常會被給予作業中任務預期最常見的CPI分布，所以它可以獨立的分析出運行的正常與否。
如果agent發現有“victim”任務受到影響變得緩慢，它將會每秒一次的對“antagonist”任務進行干涉。agent會使用一個算法來判斷“antagonist”任務的CPU占用增加與“victim”任務的遲緩是否曾在關系，依據的則是指令的周期數。
如果agent識別了一個“antagonist”並發現它是個批量作業，系統將會“通過CPU hard-capping來強制減少‘antagonist的CPU占用率’”。
鑒於CPI和Omega論文的聯合作者中都有John Wilkes，Google很有可能是通過Omega（Google大型基礎設施管理系統的一個組件）給agent發布任務。
“antagonis”任務的配置文件與CPI數據進行的是離線的記錄和存儲，這樣管理員就可以通過Google的主要網絡分析工具Dremel進行查詢。
Google工程師使用Dremel進行性能取證，用以確定“antagonists”任務，在將來他們可能為“antagonists”任務重新制定策略，讓它們在單獨的主機集中運行，然後使用這個調度進度來徹底的避免這個問題。
其中有一個需要改進的方面是處理多個“antagonists”，它將會復雜化算法；另一個則是為capping任務建立的反饋途徑。
論文中寫道：“即使這兩方面還未改善，但是CPI是個強大的、實用的工具。”
使用CPI獲得應用性能可行信息的開銷比Google其它方案來的更少，這裡還存在一個被稱為“Google-Wide Profiling”可同時對硬件和軟件性能進行追蹤的平行技術，但是只在Google小范圍的進行使用。
從整體上看，CPI提供的不只是管理，更傾向於讓集群運行的更加穩定、效率。如果你在執行搜索或者查看Gmai、通過Google服務查找地址時發現比平常需要更多的時間，那麼你可能就會被CPI冷酷及無情的當做是“antagonists”。
