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”。
