独家揭秘！阿里大规模数据中心的性能分析

举个例子，我们开发了 JVM 的一个新特性，在 SPECjbb2015 的基准测试中看到了不错的性能收益，但到线上生产环境灰度测试的时候，，发现该特性可以提升一个 Java 应用的性能、但会降低另一个 Java 应用的性能。同时，我们也可能发现即便对同一个 Java 应用，在不同硬件上得到的性能结果大不相同。这些情况普遍存在，但我们不可能针对每个应用、每种硬件都跑一遍测试，因而需要一个系统化方法来估计该特性对各种应用和硬件的整体性能影响。

对数据中心来说，评估每个软件或硬件升级的整体性能影响非常重要。比如，“双11”的销售额和交易峰值，业务层面可能主要关心这两个指标，那么这两个指标翻一倍的时候我们需要买多少台新机器?需要多买一倍的机器么?这是衡量技术能力提升的一个手段，也是体现“新技术”对“新商业”影响的一个途径。我们提出了很多技术创新手段，也发现了很多性能提升的机会，但需要从业务上也能看出来。

为了解决上面提到的问题，我们开发了 SPEED 平台。首先是估计当前线上发生了什么，即 Estimation，通过全域监控采集数据，再进行数据分析，发现可能的优化点。比如，某些硬件整体表现比较差，可以考虑替换。

然后，我们会针对软件或硬件的升级改造做线上评估，即 Evaluation。比如，硬件厂商推出了一个新硬件，他们自己肯定会做一堆评测，得到一组比较好的性能数据，但刚才也提到了，这些评测和数据都是在特定场景下跑出来的，这些场景是否适合用户的特定需求?

没有直接的答案。通常，用户也不会让硬件厂商到其业务环境里去跑评测。这时候就需要用户自己拿这个新硬件做灰度测试。当然灰度规模越大评测越准确，但线上环境都直接关联业务，为了降低风险，实际中通常都是从几十台甚至几台、到上百台、上千台的逐步灰度。SPEED 平台要解决的一个问题就是即便在灰度规模很小时也能做一个较好的估计，这会节约非常多的成本。

随着灰度规模增大，平台会不断提高性能分析质量，进而辅助用户决策，即 Decision。这里的决策不光是判断要不要升级新硬件或新版软件，而且需要对软硬件全栈的性能有一个很好的理解，明白什么样的软硬件架构更适合目标应用场景，这样可以考虑软硬件优化定制的方向。

比如，Intel 的 CPU 从 Broadwell 到 Skylake，其架构改动很大，但这个改动的直接效果是什么?Intel 只能从基准测试中给答案，但用户可能根据自己的应用场景给出自己的答案，从而提出定制化需求，这对成本有很大影响。

最后是 Validation，就是通常规模化上线后的效果来验证上述方法是否合理，同时改进方法和平台。

数据中心里软硬件升级的性能分析需要一个全局的性能指标，但目前还没有统一的标准。Google 今年在 ASPLOS 上发表了一篇论文，提出了一个叫 WSMeter 的性能指标，主要是基于 CPI 来衡量性能。

在 SPEED 平台里，我们也提出了一个全局性能指标，叫资源使用效率 RUE。基本思想很简单，就是衡量每个单位 Work Done 所消耗的资源。这里的 Work Done 可以是电商里完成的一个 Query，也可以是大数据处理里的一个 Task。而资源主要涵盖四大类：CPU、内存、存储和网络。通常我们会主要关注 CPU 或内存，因为目前这两部分消费了服务器大部分的成本。

RUE 的思路提供了一个多角度全面衡量性能的方法。举个例子，业务方反映某台机器上应用的 response time 升高了，这时登录到机器上也看到 load 和 CPU 利用率都升高了。这时候你可能开始紧张了，担心出了一个故障，而且很可能是由于刚刚上线的一个新特性造成的。

然而，这时候应该去看下 QPS 指标，如果 QPS 也升高了，那么也许是合理的，因为使用更多资源完成了更多的工作，而且这个资源使用效率的提升可能就是由新特性带来的。所以，性能需要多角度全面地衡量，否则可能会造成不合理的评价，错失真正的性能优化机会。

下面具体讲几个数据中心性能分析的挑战，基本上是线上碰到过的具体问题，希望能引起大家的一些思考。

首先是性能指标。可能很多人都会说性能指标我每天都在用，这有什么好说的。其实，真正理解性能指标以及系统性能本身并不是那么容易。举个例子，在数据中心里最常用的一个性能指标是 CPU 利用率，给定一个场景，数据中心里每台机器平均 CPU 利用率是 50%，假定应用需求量不会再增长、并且软件之间也不会互相干扰，那么是否可以把数据中心的现有机器数量减半呢?

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!