翻译：CPI2 : CPU performance isolation for shared compute clusters

CPI2：共享计算集群的CPU性能隔离

地址：https://john.e-wilkes.com/papers/2013-EuroSys-CPI2.pdf

摘要

性能隔离是云计算的关键挑战。不幸的是，Linux几乎没有一些防御机制去抵御共享资源的性能干扰，例如处理器缓存以及存储器总线，于是云上的应用会因为其他程序的行为导致不可预测的性能表现。

我们的解决方案，CPI2，使用硬件性能收集器获得的每条指令消耗的时钟周期数据去查明问题，选择出可能的作乱者，然后有选择地限制它们，以至受害者者可以返回到它们预想的表现。通过那些在相同工作中的多样任务的聚集数据，它可以自动地学习普通的和异常的行为。

我们已经在所有的谷歌共享计算集群中铺开了CPI2。这篇论文表述了让我们得出这个结论的分析，包括了个例研究以及对它解决真实生产问题的大规模评估。

1.介绍

谷歌计算集群通过在应用中共享机器去增加对硬件的利用。我们提供面向用户的，对延迟敏感的应用去执行它们峰值负载请求。但是因此不能所有的应用的同时都到达峰值负载，大多数的机器有未使用的容量，而且我们使用这容量在相同的机器去运行批处理任务。结果，绝大多数的机器运行多任务（图1）。每个机器处理的任务大致上随着CPU核数的增加而增加。

不幸的是，冲突会出现在任何被不同任务的线程共享的进程资源中，例如进程缓存与内存访问路径。冲突会对延迟敏感程序的性能产生消极影响：一个内部调查引出了一些例子，例如“在机器处理一个批处理任务期间，一个任务的延迟激增”，还有“在集群中应用程序1/66的用户流量有超过200ms的延迟而不是40ms超过一小时”。可预测的是，低延迟是用户最终满意度的关键，所有这是一个真正的问题：
当一个重要的任务或者工作遭遇这种问题时，工程师就会被任命解决这种问题。

在商业Linux操作系统内核中性能隔离的当前给我们较为局限的选择：我们可以忍受低性能（不理想的），向受害的应用程序提供额外的资源（浪费的，而且自从大多是Linux内核不再管理例如像缓存与内存管理器这种共享进程资源，它可能无法解决这个问题），或者提供给受害者独占的，非共享的资源（甚至更浪费）。这几个选择都没有吸引力。

幸运的是，为大规模计算集群设计的应用程序通常有上百到上千的类似的任务，所以使用统计学去发现性能异常值（我们称之为受害者）是可能的，然后通过减小其他任务的干扰去解决它们（我们叫这些任务为坏任务，即使这些干扰是偶然的）。发现这些异常需要一个在应用正常执行时的相对稳定的度量，而且这些度量与坏任务造成的不良行为有强相关。应用的指令消耗时钟周期（CPI）是一个度量：大多数的在我们集群中对延迟敏感的应用程序在任务与时间中有相当一致的CPI，前提是CPI在更长的一段时间取平均， 比面对单个面向用户的事务或者查询的时间更长，而且CPI计算为每个处理器类型分别完成。

这篇论文描述了CPI2，一个基于CPI度量的有用特性的系统，让下列工作自动化：

1. 观察同属于同一个作业的成百上千的任务的运行时性能，同时学习分辨正常性能和异常表现；
2. 通过检测异常值，能在几分钟之内找出性能干扰
3. 通过在线互相关分析确定哪个坏任务是可能的原因
4. （如果需要的话）通过抑制或者迁移这些坏任务去改善这些坏的行为
   结果是 引起麻烦的性能干扰可以被检测到以及被介入，这让继续在应用间分享资源成为可能，而且
   维持在较高的利用率。CPI2的原型已经被部署在了谷歌的计算集群上。

2.背景

在谷歌的集群管理系统中，延迟敏感与批处理任务都由混合作业构成，它们每一种都被映射到机器的Linux进程树中。所有的作业进程都运行在相同的资源管理容器中（），这个容器对作业可以使用CPU和内存作了限制。有许多作业的任务是常态 我们运行的96%的任务是至少包含10个任务的工作的一部分，87%的任务是包含100个或者更多任务的一部分。在相同任务中的作业是相似的：它们在相似的二进制，而且通常处理相似的数据。

一个经典的网页搜索查询包括成百上千的并行计算机器工作【6，19，29，25】，每一个机器都为最终的结果都有一部分贡献。一个终端用户的响应时间超越来回百毫秒会对用户体验造成不利的影响，所以在来回花太久的响应就会被丢掉，让搜索结果的质量降低而且浪费了生成它们的资源。用不完美的隔离去减少结果的性能变化是最小化这个问题的一个方法。

甚至MapReduce【12,18】应用也会受益：一个典型的MapReduce任务直到它所有的进程都被完成才会完成，所以缓慢的分片会推迟结果的交付。即使发现落后者并及时替换它们【39,3】通常用来提升他们的性能，但这通常会造成额外的资源消耗。而且这不总是奏效：想一下在慢存储服务器上添加额外的映射任务，会让事情变得更坏。更好的办法是消除初始的放缓。

每一个我们的集群运行在中央调度器与入口控制器，去确保这些资源没有被那些延迟敏感任务超额使用，即使它投机地过度使用分配给那些批处理任务的资源。过度使用资源是一种统计复用的形式，而且有用，因为大多数的的任务不是在所有时间使用它们的所有资源。如果调度器猜测错误，它可能一个批处理任务然后转移它到另一台机器；这并不是一个大问题-为了正确、可靠的操作，这仅仅是另一个无论如何需要处理的故障源。

任务被分类而且按优先级被列为“生产的”与被用户或者框架运行的“非生产的”’（例如，MapReduce任务默认情况是批处理的）。在一个典型的集群，7%的任务运行为生产优先级且使用大概30%的CPU利用率，与此同时非生产的任务消耗了大概另外10%的CPU【30】。

虽然在任务之间的严重的资源干扰相对来说罕见，但在在谷歌的计算负载的规模下意味着确实可能会发生，而且有时候会造成负面的性能影响。发掘这些问题的根本原因会耗费大量的精力，因为性能隔离差只是各种可能的一种情况罢了。

CPI2提升了延迟敏感任务的性能，当它们经历了干扰：发掘CPU性能隔离事件，自动化地区分问题是由哪个任务造成的，而且（选择性地）通过扼杀对手去屏蔽受害者任务。CPI2是减少和补偿响应时间变化大的众多技术之一，随着规模的提升，变得越来越重要。

我们的目标是去识别跨工作的CPU干扰以至于它可以通过限制被解决。我们并不努力去查明哪个任务是重要的

---

未完待续…